> I've taken this off list. I'm not sure we're quite addressing the same > issue.
No, I think we were at angles for a bit here. But I do believe that this is something work copying to people on the list, as you do raise a very good point. I hope this was on -current. 8) > > I've thought about this, and I think it would be a very bad idea. > > > > We want to keep this *simple*. In the case of, eg. OSS, one might > > expect: > > > > dev_oss.ko > > oss_yamaha.ko > > oss_sb16.ko > > ... > > > > There's no need to add extra crap just to identify the vendor. It > > doesn't serve any really useful purpose - we will have > > metainformation elsewhere that can be used to link modules > > comprising a product together - there's no need to duplicate it > > in the filename. > > It's not a question, primarily, of being able to identify the vendor > from the filename, it's more the case of different vendors not both > choosing the *same* filename thereby making it very difficult to install > them both at the same time. I'm saying primarily since if we do have a > vendor prefix in the filename it would make it easy to see where a > module came from but that is not my main motivation for suggesting it. > > I'm proposing that the guidleline be that anyone wishing to publish > their own modules (i.e. not contribute them to the FreeBSD source base) > should effectively create their own namespace by prefixing the filename > with a vendor code. This would make clashes a lot less likely and if > necessary a registry of vendor codes would have to be made available. > > I can't see how you can avoid namespace clashes otherwise. Third party > developers aren't likely to communicate with each other to ensure > uniqueness so it's better that the naming convention provide a mechanism > for such parties to ensure that the filenames they choose don't clash > with other people's modules. Ah, understood. I'd be inclined to use a suffix, so that our prefix-based classification scheme still worked, eg. dev_ahc_Adaptec.ko kern_descrypt_RSA.ko etc. > It'd be very irritating to pop a floppy in the machine that you got from > some vendor, run install and then find that some important module had > been overwritten from the vendor disk, or that the install failed > because it couldn't copy over all the modules. Understood now, yes. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message