RFD: Rework/extending functionality of mdev

Laurent Bercot ska-dietlibc at skarnet.org
Sun Mar 15 21:10:17 UTC 2015


On 15/03/2015 20:41, James Bowlin wrote:
>>    http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html :
>                  ^^^^^^^^^^^^^
> For goodness sake.  This appears to be an argument merely for the
> sake of having an argument.

  This is POSIX.1-2008, the very specification that Linux, and other
operating systems, are supposed to implement. It is the authoritative
reference to follow whenever you're designing Unix software. I don't
understand what your objection is.


>      A FIFO special file (a named pipe) is similar to a pipe,
>      except that it is accessed as part of the filesystem.  It can
>      be opened by multiple processes for reading or writing.

  Yes, I know the Linux man pages, and of course multiple processes
are allowed to open a pipe for reading. But there is nothing in that
page that documents what Linux does when multiple processes actually
attempt to read  on the same pipe.


>> [....] and committing to NOT changing that behaviour EVER,
> IMO this is a ridiculous demand that can't ever be met by
> any software.

  This is called specification and normalization, i.e. what standards
are for. Sure, standards change and evolve, and that's a good thing;
my point is when something is explicitly non-standardized, it is not
a good idea to do that thing and expect a fixed behaviour. There
really is no room for disagreement here.


> For my users the current busybox mdev hotplugging is not 100%
> reliable (more like 99+% reliable) which is a big pain.  I'd love
> to see other busybox hotplug solutions that are selectable at
> runtime.

  So would I, and the solution you're looking for is called netlink +
mdev -i, which is all that remains to be implemented. I would really
like to cut on the bikeshedding and see some real work done now; if
nothing has appeared when I get some time, I'll do it myself - which
so far seems the only way to get things done, and which will help you
much more than buggy solutions in search of a problem.


> It is very kind to try to help someone else from wasting time
> on a technically inferior solution but at some point it is
> better for everyone to just let them go ahead and use their
> time as they see fit.

  Multiple readers on a pipe is not technically inferior, it is
technically *invalid*. I'm not preventing anyone from coding anything,
but I will fight inclusion of buggy code into busybox, which is a
major disservice to do to you and your users.

-- 
  Laurent



More information about the busybox mailing list