From: 'Christoph Hellwig' <hch@infradead.org>
To: "Surekha.PC" <surekhap@cisco.com>
Cc: 'Naveen Burmi' <naveenb@cisco.com>,
linux-scsi@vger.kernel.org, davmyers@cisco.com
Subject: Re: Request for review of Linux iSCSI driver version 4.0.0.2
Date: Mon, 1 Dec 2003 15:38:06 +0000 [thread overview]
Message-ID: <20031201153806.A4012@infradead.org> (raw)
In-Reply-To: <002b01c3b7f8$5e6fbf20$a0074d0a@apac.cisco.com>; from surekhap@cisco.com on Mon, Dec 01, 2003 at 04:16:25PM +0530
On Mon, Dec 01, 2003 at 04:16:25PM +0530, Surekha.PC wrote:
> >please don't add an attribute group, just use the shost_attrs field in
> the host template.
>
> Can you please let me know why we should not use attribute group? Isn't
> it recommended for the driver writers to use it?
I don't think so. At least that's not how we designed the sysfs
interface for scsi.
> >iscsi_show_device() doesn't look like a good idea,what about adding an
> iscsi pseudo
> device as parent to identify the device as iscsi in sysfs?
>
> iscsi_show_device() creates sysfs file "device_type" which is checked
> while parsing "udev.config" for iSCSI device activation. Since device
> attributes like vendor, model etc reside in this directory, isn't it ok
> to have it here?
Well, the big question is what exactly does this device_type field
mean. Currently it's only implemented for iscsi so rather meaningless.
What do you think would be the values for other types of HBAs (plain
parallel scsi, firewire/sbp2, usb-storage, fc, ide-scsi, sata?).
IMHO the better choice would be to implement a fake iscsi bus in
the driver model, then you'll just have to look what bus your
host resides on in sysfs.
> If not, would like to know what field we need to use, for adding iscsi
> peusdo device as parent, I doubt this can be done with shost_attrs and
> sdev_attrs of host template.
just setup a bus_type for iscsi, create a fake struct device for it
(see scsi_debug.c for examples) and hand it as second argument to
scsi_add_host.
> >This whole find_keyword business is not good. sysfs files are supposed
> to have a single >value. We should probably do some brainstorming on
> the right API for this..
>
> Our driver has lot of user space attributes. Making each attribute as a
> separate file will endup with lots of files.
Yes.
> So we want to have all
> target specific attributes together in one file and lun specific
> attributes in another file for convinience. find_keyword() will help
> search for these keys from the cmdline specified.
Well, the whole point of sysfs is to get out of the procfs debacle
by having a defined, easily parseable structure, and that is one
value per file.
next prev parent reply other threads:[~2003-12-01 15:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-28 10:36 Request for review of Linux iSCSI driver version 4.0.0.2 Naveen Burmi
2003-11-28 12:03 ` Christoph Hellwig
2003-12-01 10:46 ` Surekha.PC
2003-12-01 15:38 ` 'Christoph Hellwig' [this message]
2003-12-01 15:40 ` James Bottomley
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=20031201153806.A4012@infradead.org \
--to=hch@infradead.org \
--cc=davmyers@cisco.com \
--cc=linux-scsi@vger.kernel.org \
--cc=naveenb@cisco.com \
--cc=surekhap@cisco.com \
/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.