On Wed, 2005-12-14 at 11:03 +0000, Alan Cox wrote:> On Mer, 2005-12-14 at 11:29 +0100, Arjan van de Ven wrote:> > > > But this means that the current usages all have to be carefully audited,> > > > and sometimes that unobvious.> > > > > > Only if you insist on replacing them immediately. If you submit a> > > *small* patch which just adds the new mutexes then a series of small> > > patches can gradually convert code where mutexes are better. > > > > this unfortunately is not very realistic in practice... > > Strange because it is how most such work has been done in the past, from> the big kernel lock to the scsi core rewrite.

1) the BKL change hasn't finished, and we're 5 years down the line. APIchanges done gradual tend to take forever in practice, esp if there's no"compile" incentive for people to fix things.

2) the scsi rewrite was a major functional change. that's different froma basically pure API change (split). Splitting functional changes to onepart of the kernel up into a sequence is very good. THat's differentthough: even in the scsi change, API changes that went outside the scsicore into the drivers were mostly done in one bang (not all of them, theones that weren't ended up being rather painful)

> You also forgot to attach> a reason you think it isnt realistic ?> that was in a follow up email