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]
Date:	Sun, 18 Feb 2007 19:27:23 +0100
From:	Joerg.Schilling@...us.fraunhofer.de (Joerg Schilling)
To:	stern@...land.harvard.edu, dougg@...que.net
Cc:	linux-kernel@...r.kernel.org, jens.axboe@...cle.com,
	James.Bottomley@...eleye.com
Subject: Re: [PATCH] Block layer: separate out queue-oriented ioctls

Alan Stern <stern@...land.harvard.edu> wrote:

> > Alternatively the SG_GET_RESERVED_SIZE ioctl could be
> > modified to yield no more than max_sectors*512 .
>
> There should be one single ioctl which can be applied uniformly to all
> CD-type devices (in fact, to all devices using a request_queue) to learn
> max_sectors.  This rules out using SG_GET_RESERVED_SIZE.

This has nothing to do with CD-type devices!
It is related to SCSI tansport.

> Furthermore, if you changed SG_GET_RESERVED_SIZE in this way you would 
> only increase the confusion.  The reserved size isn't directly related to 
> the maximum allowed DMA length, and there's no point pretending it is.  
> What if it turns out that the reserved size is smaller than max_sectors?  
> Then you'd force user programs to do I/O in chunks that were smaller than 
> necessary.

It would not increase confusion but reduce confusion because all
programs would later behave correctly without the need to change them.

Jörg

-- 
 EMail:joerg@...ily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@...tu-berlin.de                (uni)  
       schilling@...us.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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