On 05/24/2011 08:15 PM, omalleys@xxxxxxx wrote: > Quoting Gordan Bobic <gordan@xxxxxxxxxx>: > >> 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. > 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. > 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. 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. > 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. :) 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. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
