From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: dougg@torque.net, andrew.patterson@hp.com,
Christoph Hellwig <hch@lst.de>,
"Moore, Eric Dean" <Eric.Moore@lsil.com>,
jejb@steeleye.com, linux-scsi@vger.kernel.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>
Subject: Re: ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)
Date: Fri, 21 Oct 2005 14:37:29 -0400 [thread overview]
Message-ID: <43593569.1090000@adaptec.com> (raw)
In-Reply-To: <4358887C.6020200@pobox.com>
On 10/21/05 02:19, Jeff Garzik wrote:
> With the inevitable result that most ioctl code is poorly written, and
> causes bugs and special case synchronization problems :) Driver writers
> love to stuff way too much stuff into ioctls, without thinking about
> overall design.
Could you please use adjectives, like "some" or "all" before
"Device writers"? Could you also use a qualifier like, "excluding me",
etc. Thanks.
> Only for the most simple interfaces. sysfs is for exporting kernel data
> structures to userspace, using read(2) and write(2). You can quite
> literally accomplish anything with that. sysfs could export an event
> directory entry, and a response directory entry. The response dirent
> could provide all the error reporting you could ever want. That's just
> a 2-second off-the-cuff example.
For the 3-second "off-the-cuff example" see how the "smp_portal" sysfs
binary attribute works in drivers/scsi/sas/sas_expander.c at the bottom
of the file, whereby user space first writes and then reads as much data
it is expecting.
(Thus there is _no_ hardcoding of the amount of data SMP request can
return (as is done in SDI).)
Here are the tiny functions for refresh:
/* ---------- SMP portal ---------- */
static ssize_t smp_portal_write(struct kobject *kobj, char *buf, loff_t offs,
size_t size)
{
struct domain_device *dev = to_dom_device(kobj);
struct expander_device *ex = &dev->ex_dev;
if (offs != 0)
return -EFBIG;
else if (size == 0)
return 0;
down_interruptible(&ex->smp_sema);
if (ex->smp_req)
kfree(ex->smp_req);
ex->smp_req = kzalloc(size, GFP_USER);
if (!ex->smp_req) {
up(&ex->smp_sema);
return -ENOMEM;
}
memcpy(ex->smp_req, buf, size);
ex->smp_req_size = size;
ex->smp_portal_pid = current->pid;
up(&ex->smp_sema);
return size;
}
static ssize_t smp_portal_read(struct kobject *kobj, char *buf, loff_t offs,
size_t size)
{
struct domain_device *dev = to_dom_device(kobj);
struct expander_device *ex = &dev->ex_dev;
u8 *smp_resp;
int res = -EINVAL;
down_interruptible(&ex->smp_sema);
if (!ex->smp_req || ex->smp_portal_pid != current->pid ||
offs != ex->smp_req_size)
goto out;
res = 0;
if (size == 0)
goto out;
res = -ENOMEM;
smp_resp = alloc_smp_resp(size);
if (!smp_resp)
goto out;
res = smp_execute_task(dev, ex->smp_req, ex->smp_req_size,
smp_resp, size);
if (!res) {
memcpy(buf, smp_resp, size);
res = size;
}
kfree(smp_resp);
out:
kfree(ex->smp_req);
ex->smp_req = NULL;
ex->smp_req_size = 0;
ex->smp_portal_pid = -1;
up(&ex->smp_sema);
return res;
}
> Note, I'm _not_ suggesting this is the best route for an SMP interface,
> just stating sysfs generalities. sysfs is flexible enough that it could
> completely replace SG_IO (though that would not be a wise idea).
Indeed, sysfs _is_ very flexible, and with a single process open(2) it could
satisfy the transaction needed functionality.
Luben
--
http://linux.adaptec.com/sas/
http://www.adaptec.com/sas/
next prev parent reply other threads:[~2005-10-21 18:37 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-20 15:25 [PATCH 1/4] sas: add flag for locally attached PHYs Moore, Eric Dean
2005-10-20 15:55 ` Luben Tuikov
2005-10-20 16:01 ` Christoph Hellwig
2005-10-20 16:51 ` Luben Tuikov
2005-10-20 17:03 ` Christoph Hellwig
2005-10-20 17:22 ` Arjan van de Ven
2005-10-20 20:10 ` Luben Tuikov
2005-10-21 8:16 ` Arjan van de Ven
2005-10-20 20:02 ` Luben Tuikov
2005-10-21 0:01 ` Andrew Patterson
2005-10-21 0:46 ` ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs) Jeff Garzik
2005-10-21 5:09 ` Mike Christie
2005-10-21 5:41 ` Douglas Gilbert
2005-10-21 6:19 ` Jeff Garzik
2005-10-21 18:37 ` Luben Tuikov [this message]
2005-10-21 17:48 ` Luben Tuikov
2005-10-21 18:04 ` Christoph Hellwig
2005-10-21 18:12 ` Luben Tuikov
2005-10-21 18:20 ` Matthew Wilcox
2005-10-22 2:30 ` Douglas Gilbert
2005-10-22 2:54 ` Jeff Garzik
2005-10-22 3:53 ` Jeff Garzik
2005-10-22 17:14 ` Luben Tuikov
2005-10-22 17:49 ` Francois Romieu
2005-10-22 16:51 ` Luben Tuikov
2005-10-21 18:18 ` Jeff Garzik
2005-10-21 18:50 ` Luben Tuikov
2005-10-21 18:54 ` Jeff Garzik
2005-10-21 19:13 ` Luben Tuikov
2005-10-21 19:23 ` Jeff Garzik
2005-10-21 22:20 ` Stefan Richter
2005-10-21 19:22 ` Luben Tuikov
2005-10-21 19:39 ` Jeff Garzik
2005-10-21 20:41 ` Luben Tuikov
2005-10-21 21:12 ` Jeff Garzik
2005-10-21 21:24 ` Luben Tuikov
2005-10-21 21:41 ` Jeff Garzik
2005-10-21 22:14 ` Luben Tuikov
2005-10-21 22:43 ` Jeff Garzik
2005-10-22 9:26 ` Stefan Richter
2005-10-22 17:23 ` Luben Tuikov
2005-10-22 10:42 ` Stefan Richter
2005-10-22 10:58 ` Christoph Hellwig
2005-10-22 15:28 ` Sergey Panov
2005-10-22 17:19 ` Christoph Hellwig
2005-10-22 17:38 ` Sergey Panov
2005-10-24 15:18 ` Luben Tuikov
2005-10-22 18:27 ` Alan Cox
2005-10-24 13:51 ` Luben Tuikov
2005-10-24 15:41 ` Alan Cox
2005-10-24 15:14 ` Luben Tuikov
2005-10-24 15:59 ` Regala
2005-10-24 16:03 ` Regala
2005-10-24 16:13 ` Luben Tuikov
2005-10-24 16:04 ` Regala
2005-10-22 17:30 ` Luben Tuikov
2005-10-22 18:19 ` Jeff Garzik
2005-10-22 17:49 ` Stefan Richter
2005-10-24 22:09 ` ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attachedPHYs) David Lang
2005-10-24 23:09 ` Stefan Richter
2005-10-22 11:12 ` David Lang
2005-10-22 17:39 ` Luben Tuikov
2005-10-22 17:41 ` Stefan Richter
2005-10-22 17:51 ` Christoph Hellwig
2005-10-22 18:21 ` Stefan Richter
2005-10-22 18:39 ` Sergey Panov
2005-10-22 13:27 ` ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs) Stefan Richter
2005-10-22 16:09 ` Luben Tuikov
2005-10-21 19:41 ` Matthew Wilcox
2005-10-21 19:48 ` Luben Tuikov
2005-10-21 19:54 ` Matthew Wilcox
2005-10-21 20:05 ` Luben Tuikov
2005-10-21 19:46 ` Arjan van de Ven
2005-10-21 19:50 ` Luben Tuikov
2005-10-21 9:06 ` [PATCH 1/4] sas: add flag for locally attached PHYs Arjan van de Ven
2005-10-21 17:05 ` Andrew Patterson
2005-10-21 17:18 ` Arjan van de Ven
2005-10-21 18:57 ` Luben Tuikov
2005-10-21 17:32 ` Luben Tuikov
2005-10-21 1:50 ` Douglas Gilbert
2005-10-21 2:16 ` Jeff Garzik
2005-10-21 3:25 ` Douglas Gilbert
2005-10-21 18:04 ` Luben Tuikov
-- strict thread matches above, loose matches on Subject: below --
2005-10-21 20:31 ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs) Salyzyn, Mark
2005-10-21 20:31 ` Salyzyn, Mark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43593569.1090000@adaptec.com \
--to=luben_tuikov@adaptec.com \
--cc=Eric.Moore@lsil.com \
--cc=andrew.patterson@hp.com \
--cc=dougg@torque.net \
--cc=hch@lst.de \
--cc=jejb@steeleye.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.