Quoting Gordan Bobic <gordan@xxxxxxxxxx>: > 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. 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... :) _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
