lkml.org 
[lkml]   [2000]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Announce] BKL shifting into drivers and filesystems - beware


On Thu, 13 Jul 2000, Richard Gooch wrote:
> >
> > (b) means that we'll have these subtle incomptibilities between the
> > release kernel and the development kernel, and backporting of fixes
> > etc suddenly becomes much harder.
>
> But at some point you need to cut a new kernel version and live with
> it.

Yes.

The thing I hate, though, is code like

#if LINUX_VERSION_CODE >= VERSION(2,5,10)
lock_kernel();
#endif

in drivers. _Particularly_ in drivers. We'll end up living with 2.4.x for
two years or more, judging by past performance, and we'll have especially
driver writers that concentrate on the 2.4.x stuff for a long time.

Having driver interface inconsistencies like that is nasty, and the ones
we _know_ that we'll have should be minimized.

This is another reason why the open/read/write/close series is
particularly important to get done first: it's the stuff every driver
tends to do. Things like "fasync" is less critical because even if it is
used a lot by drivers, it tends to use the helper routines (so drivers
often do not need to worry over-much about locking).

This shoul dhave been the last locking issue, though. We scale too well
for words.

Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.199 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site