Hi, On Mon, 2009-11-09 at 17:03 -0600, David Teigland wrote: > On Mon, Nov 09, 2009 at 01:28:36PM -0800, Andrew Morton wrote: > > On Fri, 23 Oct 2009 21:28:17 -0200 > > Thadeu Lima de Souza Cascardo <casca...@holoscopio.com> wrote: > > > > > The current dynamic allocation of minor number for misc devices has some > > > drawbacks. > > > > > > First of all, the range for dynamic numbers include some statically > > > allocated numbers. It goes from 63 to 0, and we have numbers in the > > > range from 1 to 15 already allocated. Although, it gives priority to the > > > higher and not allocated numbers, we may end up in a situation where we > > > must reject registering a driver which got a static number because a > > > driver got its number with dynamic allocation. Considering fs/dlm/user.c > > > allocates as many misc devices as lockspaces are created, and that we > > > have more than 50 users around, it's not unreasonable to reach that > > > situation. > > > > What is this DLM behaviour of which you speak? It sounds broken. > > One for each userland lockspace, I know of three userland apps using dlm: > 1. rgmanager which is at the end of its life > 2. clvmd which is switching to a different lock manager > 3. ocfs2 tools, where the userland portion is transient; it only exists > while the tool executes. > > That said, it shouldn't be a problem to switch to a single device in the > next version of the interface. > > Dave > As well as the per-userland lockspace misc devices there are also the misc devices of which there are only one instance shared between all lock spaces:
dlm_lock - Used for userland communication with posix locks dlm-monitor - Used to only to check that dlm_controld is running (so far as I can tell) dlm-control - Used to create/remove userland dlm lockspaces I also had a look at other methods used by the dlm to communicate with userspace, and this is what I've come up with so far: configfs - Used to set up lockspaces debugfs - Used to get lock state information for debugging netlink - Used only to notify lock timeouts to dlm_controld sysfs - Used to implement a wait for a userland event (wait for write to a sysfs file) uevents - Used to trigger dlm_controld into performing an action which results in the write to sysfs mentioned above. This is netlink again, but with a layer over the top of it. If a change to the misc devices is planned, I'm wondering if it would be possible to merge some of the other functions into a single interface to simplify things a bit. In particular the netlink interface looks dubious to me since I think it should be doing a broadcast rather than the rather strange (and possibly a security issue with any process able to send messages to it and set their own pid so far as I can see). I have to say that I didn't test that, but there is no obvious check for privs that I can see in the dlm netlink code. Steve.