On Jun 26 James Bottomley wrote:
> On Fri, 2015-06-26 at 11:43 +0200, Stefan Richter wrote:
> > On Jun 22 James Bottomley wrote:
[...]
> > > Perhaps it might be wise to do this to every USB device ... for external
> > > devices, the small performance gain doe
-on card, but plenty of USB headers
available on the mainboard. Similarly, some NASes have their operating
system located on a USB-attached device. Small offices use USB-attached
disks for backup and won't detach such a disk until rotation for off-site
deposit. Not to mention embedded compu
On Nov 11 Stefan Richter wrote:
> On Nov 09 Elliott, Robert (Server Storage) wrote:
> > I recommend broadening this patch. T10 is discussing making READ (10),
> > WRITE (10), etc. obsolete in SBC-4 in favor of their 16-byte CDB
> > counterparts.
> >
> > The a
ther testing for
INQUIRY_data.VERSION >= something is a sufficiently safe test.
> 2. if 16-byte CDBs are supported, then use them; only drop down to 10-byte
> CDBs if 16-byte CDBs are unavailable. Don't make the decision by comparing
> the LBA on every IO.
--
Stefan Richter
ce for the new flag. No
wonder that it is confused with the (well named) "fix_capacity" flag.
How about "read_last_sector_separately" or something in the way?
--
Stefan Richter
-=-==--- ---= ==---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line &
on-buggy ones. The only cost of this workaround is
(1.) the code, (2.) the runtime/ bandwidth/ latency overhead for
accesses which reach the last sector.
Somebody correct me if I got something wrong.
--
Stefan Richter
-=-==--- ---= ==---
http://arcgraph.de/sr/
-
To unsubscribe from
t's what I wrote down on a piece of paper a long time ago; don't ask
me what it means in detail. :-)
--
Stefan Richter
-=-==--- ---= =-=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PR
Greg KH wrote:
> On Mon, Jan 14, 2008 at 01:21:51PM +0300, Al Boldi wrote:
>> Stefan Richter wrote:
>>> would you please explain like I asked you:
>>> - what is wrong with the current solution which tells the user to
>>> first enable SCSI to get the USB_S
you can tell the SCSI core driver at boot time (or module
insertion time) and/or at runtime to
- switch on default quirk flags,
- add quirk flags for selected devices per name matching.
Alas I don't know of a good documention how to do either of this, and I
am not familiar enough with the
wrong with the current solution which tells the user to
first enable SCSI to get the USB_STORAGE option,
- whether there are frequent end-user requests which demonstrate
that many people currently don't realize how to enable USB_STORAGE.
Please use "select" carefully, particul
config's help screen show you
whether an option was selected and by which option. xconfig calls it
"reverse dep:", menuconfig says "Selected by:".
Of course these features are merely there because 'select' creates this
problem in the first place.
--
St
Stefan Richter wrote:
> Al Boldi wrote:
>> Stefan Richter wrote:
>>> Still wrong. SCSI also needs HAS_DMA and SCSI_DMA.
>> I don't think so. SCSI selects SCSI_DMA, it doesn't depend on it.
>
> "A selects B" == "A depends on B, but please don
Al Boldi wrote:
> Stefan Richter wrote:
>> Al Boldi wrote:
>>> menuconfig USB_STORAGE
>>> tristate "USB Mass Storage support"
>>> - depends on USB && SCSI
>>> + depends on USB && BLOCK
>>> + select
tch them all on if the user
chooses USB_STORAGE. If that fails for whatever reason, say to
the user: I'm sorry Dave, I'm afraid I can't do that.
- Don't use 'select' on options which have further dependencies.
- Design and implement UIs which don't nee
[EMAIL PROTECTED] wrote:
> On Sun, 6 Jan 2008, Stefan Richter wrote:
>> build-time configuration has to deal with different, more
>> complex questions than run-time configuration.
...
> what config options must be selected by the user at build time? (i.e. no
> sane default ca
Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 02:13:09PM +0100, Stefan Richter wrote:
>> Module autoloading is quite different.
>
> Both are "hardware -> required kernel support" mappings.
>
> I know that people don't like this idea since the CML2 discussi
David Lang wrote:
> On Sun, 6 Jan 2008, Stefan Richter wrote:
>> Module autoloading is quite different.
>
> but if boot scripts can figure out what modules to autoload, why can't
> scripts be written to figure out what drives to build into a system?
Because build-time co
Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 01:32:35PM +0100, Stefan Richter wrote:
>> No, the dependency relationships alone do not carry enough information.
>> I am aware of that.
>>
>> For example, we certainly want [...]
>
> I don't think your impl
Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 01:18:48PM +0100, Stefan Richter wrote:
>> I'm afraid this can't be put into practice. (User says which hardware
>> and protocols he needs to be supported, scripts magically assemble a
>> suitable configuration.)
>
Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 12:54:04PM +0100, Stefan Richter wrote:
>> The user who wants to enable usb-storage /has/ to go into the SCSI menu
>> anyway to answer whether he needs sd, sr, st, sg, command logging...
>
> That's a different UI problem that
Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 12:29:46PM +0100, Stefan Richter wrote:
>> Adrian Bunk wrote:
>>> Duplicating the structure in each UI should be an improvement?
>>>
>>> Hardly.
>> What do you mean?
...
> You said:
> "The graphic
Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
>> Adrian Bunk wrote:
>>> Whether or not an option requires an additional subsystem like e.g. SCSI
>>> or SSB are hardware and implementation details we shouldn't bother
>&
CSI or NET).
Besides the issue of additional potentially unsatisfied dependencies and
the issue of things being enabled behind the user's back --- there is
another issue which Adrian and Al ignore:
The user who wants to enable usb-storage /has/ to go into the SCSI menu
anyway to answer whether he
Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
>> instead work on better UIs if you have got
>> trouble with the complexities of the dependencies graph. The graphic
>> UIs including menuconfig currently work best for tree-like dependenc
storage in the kernel configuration? I can
tell you that there has been no such question about sbp2 (FireWire
storage support) in years. Don't fix what ain't broken. In fact, don't
/break/ what ain't broken by adding more of the (as yet) broken 'select'
everywhere.
-
Al Boldi wrote:
> -comment "NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may"
> - depends on USB
> -comment "also be needed; see USB_STORAGE Help for more information"
> - depends on USB
Your patch description fails to mention what is wr
26 matches
Mail list logo
