> 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
