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