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

Re: A newbie's view



29-Jan-99 09:52 you wrote:
>> 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.  :-)

It's really madness. We MAY BE will got support for some new hardware (not
sure, but may be -- just now all hardware in our new school PII-350 Dell's
are supported out-of-box by Linux with except of USB) but we'll lost stability
and this is BIG loss. No way. It's IMHO, of course.

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

It CAN be done. The end result will be just bloat, loss of srtability and
LOSS OF SIMPLICITY for driver writers! It's far more easy to recompile
driver with new kernel then to work around limitations in "stable API".
May be UDI folks will produce something usable of course but Windows has
"stable" API and still drivers from NT 3.51 could not be used in NT 4.0,
drivers from Windows95 could not be used with Windows98 (ok, ok, SOMETIMES
they could be used if you are REALLY lucky), etc.



-
Linux-future: thinking about the future of the Linux kernel
http://humbolt.nl.linux.org/lists/