Quoting Gordan Bobic <gordan(a)bobich.net>:
On 05/24/2011 08:15 PM, omalleys(a)msu.edu wrote:
> Quoting Gordan Bobic <gordan(a)bobich.net>:
>
>> On 05/24/2011 07:27 PM, Alexander Boström wrote:
>>> mån 2011-05-23 klockan 15:15 +0100 skrev Gordan Bobic:
>>>
>>>> What I'm pondering now is something like a dkms package for the
>>>> cryptodev kernel module, but I seem to remember reading somewhere that
>>>> dkms is a non-Fedora RHEL thing. What do you guys think would be the
>>>> best way to approach it, especially since we don't have
"standard"
>>>> kernels at the moment?
>>>
>>> It's probably a lot easier to just patch your kernel build (or ask
>>> whoever builds your kernel to do it). Then you won't need kernel build
>>> tools installed on your little arm device.
>>
>> I really don't think that's a big deal. Cryptodev module takes seconds
>> to build, and even if you are building your own kernel, it means you can
>> just install the new kernel, and the new module with automatically be
>> built for it. So it still saves effort.
>
> I think this is a bigger deal then you assume. I sure as heck don't want
> a compiler sitting on my embedded device facing the outside world
You don't want to be updating the kernel on your embedded device without
ample preparation either.
Well depends on how you look at it. It can be a valuable learning
experience trying to figure out how exactly to recover from your
mistake.
> or on my desktop system,
So you don't like having nvidia/ati accelerated graphics with
manufacturer provided drivers either, then? Or LSI SAS controllers? Or
anything else that relies on dkms to keep it's drivers up to date.
I have to recompile them for various kernels. I have the same issue
with OpenAFS if the package hasn't been updated yet and a new kernel
is released.
> just the same as I don't put a compiler on a
> production server system either.
See above. The LSI MPT driver that ships with the kernel on RHEL is
quite a long way out of date. I guess you could have a build machine
template for every type system you have, but that's impractical if you
have a lot of heterogenous hardware.
I do have a build environment for a number of different services.
I moved most of the dev environments to virtual machines though.
Besides - I don't see a big deal. If you don't like dkms
don't use it -
build the drivers the hard way. For most people, myself included, it's
an acceptable solution.
> It is just as easy to compile a rootkit
> as it is a dkms.
If somebody has gained shell access to your box, you've already lost, so
I don't see this as a particularly viable argument.
Yes but they may have shell access and build the kit to gain root access.
> Embedded also has space at a premium and dev tools and
> libraries can eat up space.
If it's embedded, it doesn't get updated often or without good reason,
and if it really is embedded, then you are probably developing in a
dedicated environment and planning to deploy on many identical devices.
In that case you can just push out the driver with the kernel package
and be done with it. I don't see the two approaches as in any way
contradictory. The fact that the solution doesn't fit your requirements
doesn't mean it fits nobody's. I posted the docs on how to do it -
whether you do it that way or dkms wrapped is entirely up to you. :)
I think the docs were actually well written. I quite enjoyed reading them.
The only point I'm really making is that dkms is a standard,
recognized
way of doing things like this. It may not fit everyone's requirements,
but it fits a lot of people's requirements. I'd love to see it become a
non-issue by bundling the driver/headers in the kernel rpms when those
become available for popular devices, but until then I think dkms would
make it much easier for most people who don't want to get their hands
dirty with doing it all manually.
I understand your argument. It seems strange that you would be making
the argument given you are one of the people who likes to get their
hands dirty. :)
I just think there has to be a better way to do it, sans moving to a
bsd style kernel... :)