Re: ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)

Luben Tuikov
2005-10-21T17:48:58Z

On 10/20/05 20:46, Jeff Garzik wrote:
> Consider what an ioctl is, overall: a domain-specific "do this
> operation" interface. Which, further, is nothing but a wrapping of a
> "send message" + "receive response" interface. There are several ways
> to do this in Linux:
>
> * block driver. a block driver is nothing but a message queue. This is

Not quite. This maybe the way it operates, but it is called "block"
for a reason.

> why James has suggested implementing SMP as a block driver. People get
> stuck into thinking "block driver == block device", which is wrong. The
> Linux block layer is nothing but a message queueing interface.

Now, just because James suggested implementing the SMP service as a block
device you think this is the right thing to do?

How about this: Why not as a char device?

At least MS isn't suffering from the "no to specs" syndrome which
the Linux community seems to be suffering...

SMP as a Block device????

You need to see the history of SMP and its intended use.

> * netlink. You connect to <an object> and send/receive messages. Not
> strictly limited to networking, as this is used in some areas of the
> kernel now for generic event delivery.

This is very similar to the binary attr file "smp_portal" in
drivers/scsi/sas/sas_expander.c, bottom of file.

> * char driver. Poor man's netlink. Unless its done right, it suffers
> from the same binary problems as ioctls. I don't recommend this path.
>
> * sysfs. This has no inherent message/queue properties by itself, and
> is less structured than blockdrvr or netlink, so dealing with more than
> one outstanding operation at a time requires some coding.

Exactly! SMP. (binary attr file)

Luben
--