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: <1222408937.3265.17.camel@localhost.localdomain>
Date:	Thu, 25 Sep 2008 23:02:17 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Jing Huang <huangj@...cade.COM>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org,
	Ramkumar Vadivelu <rvadivel@...cade.COM>,
	"Srikanth Rayas (CW)" <srayas@...cade.COM>,
	Vinodh Ravindran <vravindr@...cade.COM>
Subject: RE: [PATCH 5/6] bfa: Brocade BFA FC SCSI driver submission (2ndtry)

On Thu, 2008-09-25 at 21:49 -0700, Jing Huang wrote:
> The reason we creating our own sysfs directory under /sys/devices path
> was we felt the fc transport and scsi host attributes are not enough for
> all the HBA management features we want to have.

This isn't really a valid reason.  We use the fc transport class to
share infrastructure and provide a common interface for users.  If you
need more, we can discuss adding features to the fc transport class if
they would be useful to fibre drivers in general.  If they're not useful
to other drivers, then you can add pieces specific to your driver for
them, but the functionality that's already in the fc transport shouldn't
be duplicated by that.

>  We have ioctl in our
> non opensource driver, and we want to have something to emulate all/most
> of the IOCTL functionality we have in the opensource driver. We provide
> multi-level of driver/fw statistics info to the user, and we want to put
> those info under a separate directory instead of throw them all under
> scsi_host.

That's how the fc transport class currently operates.  It's statistics
all appear in a "statistics" directory under the host.  If you use it
(and add the ones you need that are missing) everyone will be happy and
you won't need to worry about creating the directories.

>  I just didn't know how to create a subdirectory under scsi/fc
> host. Currently, we only implement a small portion of all the IOCTL
> functionalities. We want to know if this is acceptable in the upstream
> kernel. 
> 
> I agree that there are a lot of redundancy with the attributes we
> created under scsi_host. We will clean them up.

James


--
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