Messages in this thread | | | Date | Fri, 2 Jul 1999 18:45:58 -0400 (EDT) | From | Stephen Frost <> | Subject | Re: Standard for module delivery |
| |
On Fri, 2 Jul 1999, Stephen Williams wrote:
> > sfrost@ns.snowman.net said: > > Just curious, why not have it included in the mainstream kernel? > > Not enough of a market to justify bloating the kernel tarball. They > tend to be slightly esoteric (read: expensive). I do have major numbers > assigned by the right authorities.
Hehe, there's LOTS of esoteric stuff in the kernel. :) How big can your drivers be? I know personally I'm ALOT happier when stuff is in the kernel as opposted to when I have to go hunt it down...
> 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...
> 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 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).
> 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...
Stephen
- 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/
| |