[systemd-devel] systemd inquiry

[Kay Sievers]

On Tue, Apr 10, 2012 at 16:26, Mark Hounschell <markh at compro.net> wrote:
> On 04/10/2012 09:10 AM, Kay Sievers wrote:

>> We do not support any kernel device driver which does not create the
>> device nodes on its own from inside the kernel. Such drivers cause
>> problems and will fail for various non-interesting reasons. You really
>> must hook up the kernel driver to register the devices with the kernel
>> driver-core; it's just a few lines to add.
>>
>
> Ya, I've thought about this. We have actually converted all our drivers to
> do this in kernel. This one is actually a 3rd party driver that we've had to
> maintain because the original mfgr no longer does. Even though they still
> make the cards. Anyway, I suspect this type of issue won't just go away
> because of what your saying here so the info that Colin is giving is very
> useful to me and others may also find it useful. For the sake of myself I
> will be attempting to use what Colin has suggested, but then also maybe
> reevaluate fixing up the driver. It just uses so many device nodes that I
> would rather it all be done in user land. Earlier I said around 30 device
> nodes per card but it is actually around 180 per card with many different
> majors and minors. Forcing the kernel module to implement this would for
> sure be a very messy thing.

No, not at all.

You register cdevs (or blockdevs) in the kernel anyway, otherwise the
userspace-created nodes would not do anything when you open them. At
the very same time you register the cdev (blockdev) minor you just
register the node (with struct device) in the kernel. It's just a few
lines on top of what you do anyway.

There is no general problem to create 100s or 1000s of nodes per device.

>> Doing mknod() in userspace is just too fragile and does not fit into
>> any synchronization logic of udev or systemd, it is not even expected
>> to work reliably with these tools.
>
> I don't know what you mean by fragile but using mknod in user land has been
> around in the "unix" world forever and I suspect is not likely to just
> disappear from the Linux world just because systemd/udev developers don't
> like it or haven't figured out what to do about it yet.

Sure, we have figured it out; we refuse to work around such drivers. :)

It does not matter at all what UNIX did, it did a lot of other stuff
too which makes not much sense, and it has nothing to do how
Linux/systemd/udev works today.

Sure, you can try to hack around the problem, but be aware that this
might not work as you expect, and that the core infrastructure does
not really deal with setups like that.

> In any case I understand what you are saying and thanks.

Cool.

Cheers,
Kay