The Right Thing to do would be option 1 (change the parallel tape
device and driver since it stomped on an existing device).
>(1) I rename my pt device and driver to something else. This will make
> a mess for people who are using pt from 2.0.35 (which SuSE and RedHat
> are already distributing).
Option 2 is asking for problems with people being confused as to
which device they are talking about when they refer to pt. A
support nightmare.
>(2) Leave the device name as pt, but rename the driver to something else.
> This is ugly, but it breaks slightly fewer things.
Option 3 would be ok, except you are assuming that no one is
maintaining the PacketTwin driver, and no one has written
software that depends on the pt driver being the PacketTwin.
(I would look to the person who wrote / maintains the PacketTwin
driver and discuss the possible problems with this option before
attempting to do this.) It also sets a bad precedent for changing
device names because someone else wants to use that name.
>(3) Rename the PacketTwin driver to something else. Since there is no
> association between the driver's file name and a device node, this
> is fairly transparent.
Option 4 is not nice, ignoring a problem will only create larger
ones later. A person using SuSE decides they need PacketTwin
support, so they grab a kernel source tree and compile their own
and boom - instant problem.
>(4) Another solution is to let the distribution builders find their own
> ways around the problem - in other words, to ignore it. SuSE omitted
> the PacketTwin from their configuration.
Option 5 is not a good option, you claim it will only happen to people
who are making distributions. I claim it could happen to anyone who
copiles their own custom kernel. Changing the Makefile to fix a programming
error sounds like something M$ would do (smile - that's a joke).
>(5) Finally, we could deal with this by fixing the Makefile to
> abort with a clear explanation when it detects that a module of
> the same name is already linked into linux/modules. This is
> arguably the correct fix - since the probability of this
> happening to anyone except a distribution builder is
> effectively nil.
Basically I see this as a person having great intentions, creating a
useful piece of software, but not following through on the development
by researching the driver name before releasing the driver to the world.
This raises the question - who is responsible for coordinating device
driver names and numbers for the kernel? If no one is, this will happen
again in the future as support for more devices are added by more people
with less experience. (For those who say put your money where your mouth
is, I would be willing to maintain such a database if it does not already
exist.)
Pat
pouellet@eng.utoledo.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html