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