linux-kernel - Re: [PATCH] SCSI: userspace cannot use scsi_command_size_tbl, COMMAND_SIZE and scsi_device

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1246200282.4190.13.camel@mulgrave.site>
Date:	Sun, 28 Jun 2009 09:44:42 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	James Smart <James.Smart@...lex.Com>
Cc:	Boaz Harrosh <bharrosh@...asas.com>,
	Jaswinder Singh Rajput <jaswinder@...nel.org>,
	Olaf Hering <olh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>,
	Benny Halevy <bhalevy@...asas.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH] SCSI: userspace cannot use scsi_command_size_tbl,
 COMMAND_SIZE and scsi_device_type

On Sun, 2009-06-28 at 10:32 -0400, James Smart wrote:
> Sorry folks --  the nuance of the clibrary having it's own version of a 
> kernel header for distros was completely unknown to me.
> 
> Christoph mentioned this to me last week, with the recommendation to 
> back out the patch and move the other headers that were exprted into 
> include/linux - thus nothing in include/scsi gets export.  No Problem. 
> and I'll do so shortly.

Actually, I'm not sure that's the best way forwards ... the idea of
include/scsi is to group all the SCSI headers together; having to put
them in include/linux if they need to be exported defeats that purpose
slightly.

I think the first point of business might be to find out why (or even
if) glibc still wants its own SCSI headers.  After all, we now have
quite an anomaly: if you use the old SG_IO ioctl, glibc supplies the
header in include/scsi/sg.h; if you use the new bsg SG_IO then we supply
it in include/linux/bsg.h

> How does a lowly contributor track these kind of nuances ?

If the creator of the kernel header exports missed this problem for a
year, I think it's safe to assume you don't lose brownie points for not
spotting it either.

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/