linux-kernel - Re: [PATCH 1/1] cciss: resubmit export uid, model, vendor, rev to sysfs

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]

Message-ID: <ac3eb2510904080934o46a5375qf70ee77ec3ab7171@mail.gmail.com>
Date:	Wed, 8 Apr 2009 09:34:37 -0700
From:	Kay Sievers <kay.sievers@...y.org>
To:	Andrew Patterson <andrew.patterson@...com>
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, Apr 8, 2009 at 09:24, Andrew Patterson <andrew.patterson@...com> wrote:
> 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.

Do what you have today, just make sure all your devices are uniquely
named, and assigned to the cciss bus_type. There can be no hierarchies
in /sys/bus/*/devices, there are only symlinks. The hierarchy is only
in /sys/devices/, and if I correctly look at what you have, you have
that already.

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/