On Fri, Mar 08, 2013 at 05:05:33PM -0600, scame...@beardog.cce.hp.com wrote:
> We are not expecting to be able to boot from the device in the first
> iteration,
> so it's not as if we would need support instantly (not that I imagine we could
> get it instantly anyway), and it's not clear that it m
On Fri, Mar 08, 2013 at 05:49:11PM -0500, Lennart Sorensen wrote:
> On Fri, Mar 08, 2013 at 04:34:28PM -0600, scame...@beardog.cce.hp.com wrote:
> > I get ~4x the IOPSs with a block driver vs. scsi driver due to contention
> > for locks in the scsi mid layer (in scsi_request_fn). It's the
> > diff
On Fri, Mar 08, 2013 at 04:34:28PM -0600, scame...@beardog.cce.hp.com wrote:
> I get ~4x the IOPSs with a block driver vs. scsi driver due to contention
> for locks in the scsi mid layer (in scsi_request_fn). It's the
> difference between the device being worth manufacturing vs. not.
Well that st
On Fri, Mar 08, 2013 at 04:56:32PM -0500, Lennart Sorensen wrote:
> On Fri, Mar 08, 2013 at 02:07:18PM -0600, scame...@beardog.cce.hp.com wrote:
> > I'm just wondering if there are best pratices for new linux block
> > drivers that are adding new devices nodes of which grub is currently
> > not cog
On Fri, Mar 08, 2013 at 02:07:18PM -0600, scame...@beardog.cce.hp.com wrote:
> I'm just wondering if there are best pratices for new linux block
> drivers that are adding new devices nodes of which grub is currently
> not cognizant.
>
> E.g. when we added the HP Smart Array cciss driver to the ker
Hi,
I'm just wondering if there are best pratices for new linux block
drivers that are adding new devices nodes of which grub is currently
not cognizant.
E.g. when we added the HP Smart Array cciss driver to the kernel
many years ago, it had device nodes like /dev/cciss/c*d*, and there's
code in
