lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 08 Apr 2009 16:24:13 +0000
From:	Andrew Patterson <andrew.patterson@...com>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	"Mike Miller (OS Dev)" <mikem@...rdog.cca.cpqcorp.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	LKML-SCSI <linux-scsi@...r.kernel.org>, mike.miller@...com
Subject: Re: [PATCH 1/1] cciss: resubmit export uid, model, vendor, rev to 
 sysfs

On Wed, 2009-04-08 at 05:26 -0700, Kay Sievers wrote:
> On Tue, Apr 7, 2009 at 23:19, Jens Axboe <jens.axboe@...cle.com> wrote:
> > On Tue, Apr 07 2009, Mike Miller (OS Dev) wrote:
> 
> > The patch looks fine to me, but my sysfs foo is very weak though. CC'ing
> > Kay, perhaps he can help take a quick look at this.
> 
> >> + * Initialize sysfs for each logical drive.  This sets up and registers
> >> + * the 'c#d#' directory for each individual logical drive under
> >> + * /sys/bus/pci/devices/<dev/ccis#/. We also create a link from
> >> + * /sys/block/cciss!c#d# to this entry.
> >> + */
> >> +static int cciss_create_ld_sysfs_entry(struct ctlr_info *h,
> >> +                                    drive_info_struct *drv,
> >> +                                    int drv_index)
> >> +{
> >> +     device_initialize(&drv->dev);
> >> +     drv->dev.type = &cciss_dev_type;
> >> +     dev_set_name(&drv->dev, "c%dd%d", h->ctlr, drv_index);
> >> +     drv->dev.parent = &h->dev;
> >> +     return device_add(&drv->dev);
> >> +}
> 
> If I read that correctly, you are creating a hierarchy of devices
> where the devices do not belong to any subsystem? This is what we need
> to avoid in almost all cases, we need a "subsystem" link in sysfs.
> 

Yes, but apparently mistakenly.

> I wold expect the cciss devices not to be a magic, silently created,
> subdirectory of a pci device, but to have their own "cciss" bus in
> sysfs, so the created devices get proper events at creation time. All
> the cciss devices would show up in its own directory
> /sys/bus/cciss/devices/*.
> 
> I think, you should name all "cciss bus devices" uniquely, and assign
> them to a "cciss bus_type". We really do not want unclassified devices
> in the chain of parent devices of a block device.
> 

I'll try this.  Although I am wondering whether to put hosts or logical
drives in /sys/bus/cciss/devices (or both). Can I do what I am doing
now, just moving it to /sys/bus/cciss/devices? That
is, /sys/bus/cciss/devices/ccissX/cYdZ.

Andrew

> Or do I missing something here?
> 
> Kay


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ