On 05/24/2011 08:54 PM, omalleys@xxxxxxx wrote: >> 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. As opposed to using wget, curl, or even the magic /dev/tcp from shell to download it pre-cooked? Sorry, I just don't see it making a difference. >>> 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. By all means, feel free to paste/link on the official wiki. :) >> 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 _don't mind_ getting my hands dirty _when I have to_, but I do like to come up with a solution that I have to implement once, and from there on it takes care of itself. > I just think there has to be a better way to do it, sans moving to a bsd > style kernel... :) Feel free to chase cryptodev inclusion in mainline - I'm totally for that, I just think it'll take years and I am simply not prepared to wait for it. There is also an argument that we should perhaps involve the developer of the module in this conversation, too, and see what they think. :) Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
