> Hmm.. Is modutils under RedHat modified then? Or does modutils
> somehow pull something different than what uname -r reports? It seems
> to me that modprobe/insmod/etc have to have some way of knowing where
> the stuff is, hopefully it's just pulling something else, and there isn't
> a RedHat-specific version of modutils...
No. There are just specific version of init scripts :-)
>> sfrost@ns.snowman.net said:
>> > Kernel headers and such are kind of a pain though, you could be like
>> > (I think) the PCMCIA package and have it ask in an install proggie
>> > where the kernel source is.
>>
>> It is my (NSH) opinion that the kernel headers should be in /usr/include/linux
>> unless to are doing something special, like compiling for some other
>> kernel version. This simple rule would allow the module writer to just
>> presume in the makefile/spec file and let the expert deal with the odd
>> cases as needed.
> Well, except that the version of the kernel in /usr/include/linux is
> not always the same as the version of the kernel you have running (If you
> compile your own). It used to be a link to /usr/src/linux/include/linux,
> but that is no longer the case under glibc2.
It IS true under glibc2. glibc2 just do not use /usr/include/linux at all ...
>> It is pretty much required that a practical package install the module
>> without any interaction from the installer. That is what an RPM package
>> does, and anything less is an annoyance to my customer, who is most often
>> an NT user who is already slightly pissed that he has to use the keyboard
>> in the first place. (Many do not even know how to list a directory in DOS.)
> Yikes, but the only other thing I can think of would be like finding
> it on your own, or only supporting certain versions of like RedHat w/
> specific kernels (Yes, very, very ugly).
But it will work IMO :-)) If user can compile special version of kernel not
shipped on CD he probably can compile your sources as well and if not he is
running version shipped on CD...
>> And by the way, including my driver in the kernel source tarball won't
>> solve anything, as the user will still need to config the bloody thing
>> to get it to go, and frankly that is even worse.
> Hrm. I don't know what to tell you about dealing w/ the kinds of
> users you described, however, for myself (And no, I'm not really a kernel
> developer or anything), I much prefer to find the driver in the kernel,
> and the docs for configing the driver in the Documentation/ directory.
> Now if you've got seperate proggies that are required to work
> w/ the thing, perhaps a link from the info in the Documentation/ directory
> would suffice. That at least is how I prefer it. :) But then, I'm pretty
> familiar w/ linux...
Yes, it's exactly "Linux way" to deal with such problems... But it does not
solve problem as well: how to update driver without updating of the whole
kernel ? I'm just can not see any proper way to solve this problem :-/
-
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/