Before anybody complains, I will shortly be helping a friend to write
a device driver for Linux, and I thus need to get this sorted out.
There is a strict time limit for the driver project since it is being
done as a final year project for a university degree.
>>>> 90% of the objections to having devfs in the kernel
>>>> are easily solved with "well don't use it then".
>>> Wrong. Having devfs in the kernel has an impact on _all_ devices,
>>> if they use it or not. Giving the option has even more impact
>>> here than just forcing it one way or the other.
>> I'm sorry, but I fail to understand your reasoning behind this
>> statement. Could you please clarify? How is a driver which
>> presents a traditional major/minor number interface affected by
>> the presence of a devfs (which, presumably, uses a different
>> interface to the driver).
> That is the point: There are _two_ interfaces to the driver.
Are you sure of that?
My understanding was that the devfs interface just called the entry
points that get called as a result of accessing the standard node
file. If so, the drivers just have to export the same set of entry
points they would export in the absence of devfs.
> As a driver author I must make sure _both_ work, so I must study
> both; I'll have to compile four kernels (devfs/module) just to
> check that it doesn't break.
Only if devfs uses different entry points to the standard node file.
> I must check that I don't hijack a major number, and that I
> don't take over the device name for something else (this has to
> be done in the driver, if I understand a recent post correctly).
I saw the post you're referring to, and I found said post very
confusing, so I don't intend to comment thereon.
> I must set up a default permission in the driver, and also add
> it to MAKEDEV.
Certainly needed if devfs is NOT in use, and a good idea even if it is.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
-
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.tux.org/lkml/