Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sat, 3 Jul 1999 22:29:18 +0400 (MSD) | Subject | Re: Standard for module delivery |
| |
In <Pine.LNX.4.05.9907021830260.750-100000@ns.snowman.net> Stephen Frost (sfrost@ns.snowman.net) wrote: >> sfrost@ns.snowman.net said: >> > As for your questions, how does RedHat do it? I've used RedHat, and >> > IIRC have had a 'make modules_install' work and install things into / >> > lib/modules/`uname -r`/*, and everything was happy. >> >> Only if you build your own kernel. If you use the kernel-modules RPM >> from the CD (or updates) then the modules are in /lib/modules/`uname -r`-N/* >> where -N is the rpm version. Perhaps it would be an adequate fix if >> uname -r printed '2.0.36-1' like is done in the ac series kernels.
> 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/
| |