Re: [ANNOUNCE 0/7] Open-iSCSI/Linux-iSCSI-5 High-Performance Initiator

[Dmitry Yusupov <dmitry_yus@yahoo.com>]

On Sat, 2005-07-30 at 15:23 -0500, James Bottomley wrote:
> On Sat, 2005-07-30 at 12:53 -0700, David S. Miller wrote:
> > From: James Bottomley <James.Bottomley@SteelEye.com>
> > Date: Sat, 30 Jul 2005 12:32:42 -0500
> > 
> > > FIB has taken your netlink number, so I changed it to 32
> > 
> > MAX_LINKS is 32, so there is no way this reassignment would
> > work.
> 
> Actually, I saw this and increased MAX_LINKS as well.  I was going to
> query all of this on the net-dev mailing list if we'd managed to get the
> code compileable.
> 
> > You have to pick something in the range 0 --> 32, and as is
> > no surprise, there are no numbers available :-)
> > 
> > Since ethertap has been deleted, 16-->31 could be made allocatable
> > once more, but I simply do not want to do that and have the flood
> > gates open up for folks allocating random netlink numbers.
> > 
> > Instead, we need to take one of those netlink numbers, and turn
> > it into a multiplexable layer that can support an arbitrary
> > number of sub-netlink types.  Said protocol would need some
> > shim header that just says the "sub-netlink" protocol number,
> > something as simple as just a "u32", this gets pulled off the
> > front of the netlink packet and then it's passed on down to the
> > real protocol.
> 
> I'll let the iSCSI people try this ...
> 
> Alternatively, if they don't fancy it, I think the kobject_uevent
> mechanism (which already has a netlink number) looks like it might be
> amenable for use for most of the things they want to do.

In fact, during design phase we've considered to use kobject_uevent() as
well but (if i recall correctly), it didn't fit for the simple reason
that if we want to have that much code in user-space, than we need to
have more control on netlink socket and need to pass binary data back
and forth.

It would be nice to set MAX_LINKS to 64 and close this issue for now,
since I'm pretty sure some other apps might find out kobject_uevent()
not suitable for their needs too.

Dima

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/