linux-kernel - Re: libata: set queue SSD flag for SSD devices

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: <1223743124.4159.27.camel@localhost.localdomain>
Date:	Sat, 11 Oct 2008 18:38:44 +0200
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org, torvalds@...l.org
Subject: Re: libata: set queue SSD flag for SSD devices

On Sat, 2008-10-11 at 09:04 -0700, Arjan van de Ven wrote:
> On Sat, 11 Oct 2008 17:44:13 +0200
> James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> 
> > 
> > > So we need something a bit more involved, but not too complex. A
> > > fine line...
> > 
> > It's a policy ... just let userspace do it so the user can tune it.
> > That's what EMC does now (except I think they key of inquiry strings
> > rather than cache size).
> 
> 
> while the chosen elevator obviously is policy, the kernel really should
> pick a sensible default based on what it knows.
> Lets put it this way: if userland needs to do a tuning to the kernel
> based on data only provided by the kernel, and will always do it the
> same way, we should have made that choice the default policy in the
> kernel in the first place.

Well, this is a bit of a nasty layering problem.  We certainly don't
want the Block layer to know how to poke at SATA, SCSI and other
esoteric media to see what elevator should be the default, so we'd have
to craft a new block API that the lower subsystems would implement for
this.  I'm really not sure it's worth the trouble when the boot system
can do it simply from userspace, but I'll defer to Jens.

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/