Re: [Announce] BKL shifting into drivers and filesystems - beware

From: Erik Verbruggen (ejv@cs.kun.nl)
Date: Fri Jul 14 2000 - 04:47:55 EST


On Thu, Jul 13, 2000 at 08:06:33PM +1000, Andrew Clausen wrote:
> "Jeff V. Merkey" wrote:
> > > To maintain the "forwarders" sounds like as much (if not more) work than
> > > just fixing the errant modules in the first place. Plus you loose the
> > > flexibility of changing data structures and functions which are inlined and
> > > just #included, which is exactly the advantage Linus was talking about.
> >
> > Guys!!!!!
> >
> > Well, let's just wait until the monolithic kernel is 500MB in size and
> > requires 8GB of ram to load (or alternately the .config file requies an
> > 8GB disk to hold it when you build Linux).
> >
> > What I am hearing are no technical arguments, just "control, control,
> > control ...".
>
> "forwarders" puts the problem (out of date drivers) out of sight, and
> out of mind. So, we'll end up with 10000 out of date drivers, and no-one
> will care enough to fix it.
>
> Having things fail to compile is good encouragement to fix drivers ;-)

This is why Microsoft introduced a certification program for drivers
compatible with Win2000. You'll get a warning saying that the driver is
not certified, and could break the kernel. Most drivers still (seem to)
work, which is why everyone I know does use the (maybe) outdated
drivers. But this indicates that Microsoft has the same problem of
"correct" drivers, and forces driver writers to update their code this
way.

I think this also loops back to the release timing issue: if you have
lotsa changes in one release, big chance that there are a number (> 1)
of changes that will affect a driver. I think it's easier for driver
writers to cope with one or two changes at a time. When a change doesn't
get in in the next release because it is not yet stable enough, it
probably will get in into the next release. This also gives some
perspective on what things will change in which (near-future) release.

But then again, this definitely requires some communication, which as
Alan pointed out, isn't always done..

Erik.

-- 
Erik Verbruggen, ejv@cs.kun.nl, Daneel on LinuxNet & GimpNet,
room A5005 science faculty KUN, phone: +31-24-3652229

- 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/



This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:19 EST