[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A newbie's view



On Fri, Jan 29, 1999 at 01:43:00AM +0100, Krzysztof G. Baranowski wrote:

> Version independend modules aren't so easy to implement in Linux
> IMO.[1] They would require stable, binary backwards compactible API
> for modules. Implementing such kind of API would require adding
> another layer to the kernel, which would talk between your driver
> and kernel internals... and this would be just pure bloat which
> would cost you extra complexity and give you almost nothing. I've

   Bloat that could itself go in a module loaded only when needed,
gaining the user a safety net if he forgets an essential module and
possibly opening an avenue for hardware vendors to put a Linux module
on their CDs without the versioning problems that make it impossible
now.

   I need a code name ... let's call it Project Promiscuous Penguin.
Then just as multiple xxx can be searched for
/lib/modules/VERSION/xxx/module.o, we could also search for
/lib/modules/promiscuous-penguin/xxx/module.o, assuming that the
support is either compiled in or loadable from
/lib/modules/VERSION/misc/promiscuous-pengiun.o at that time.  Make
the compatibility layer a default Y for the newbies' safety with M
supported so veterans can trim the fat.  Distributions can ship a
nicely stocked /lib/modules/promiscuous-penguin.

   (I probably shouldn't even mention that it may just give them
an opportunity to produce a non-GPL module, although the performance
difference would be incentive to help in the development of a freely
distributable version too.  No, I definitely shouldn't mention that.
:-)

   Actually, change /lib/modules/promiscuous-penguin in the above to 
/lib/modules/MAJOR.MINOR.x -- compatibility within 2.x.* is the goal,
not some dream of compatibility across totally new versions.

> recently read a litte documentation of WinDDK and this is what NT
> does. Believe me this way lies madness  :-)

   And new hardware support as easily as Windows, and desktop
acceptance.  Not that that is at all different than madness.  :-)

> [1] Note that CONFIG_MODVERSIONS buys you almost nothing. It works OK
>     when symbol doesn't change, but when it changes you have to recompile 
>     your module anyway.

   I always enable it ... it catches a percentage of cases where
the module wouldn't have worked anyway but you accidentally try
loading it anyway.  Although the way things are I almost think the
kernel should export an int kernel_cookie, from a randomly 'make
config'-generated <linux/cookie.h>, which would also be compiled
into modules and then checked at load-time.

   Now, I don't know enough to go *do* any of this even if I had so
much as a spare minute.  I'm just free-thinking here.  There may be a
good reason why it can't be done at all ... I just have a feeling that
while it may be ugly, slow as hell, and possibly not worthwhile, it is
still possible.

-- 
Rich Derr, sysadmin                   Have ssh, Will Telecommute
Web Design Group   www.webdesigngroup.com   TEL: +1 312 951 6588
-
Linux-future: thinking about the future of the Linux kernel
http://humbolt.nl.linux.org/lists/