linux-kernel - Re: [SCSI] aic94xx: new driver

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: <1186761988.7615.10.camel@shinybook.infradead.org>
Date:	Sat, 11 Aug 2007 00:06:28 +0800
From:	David Woodhouse <dwmw2@...radead.org>
To:	James Bottomley <James.Bottomley@...elEye.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [SCSI] aic94xx: new driver

On Fri, 2007-08-10 at 08:52 -0700, James Bottomley wrote:
> On Fri, 2007-08-10 at 23:09 +0800, David Woodhouse wrote:
> > On Sun, 2006-09-24 at 04:00 +0000, Linux Kernel Mailing List wrote:
> > > --- a/include/scsi/scsi.h
> > > +++ b/include/scsi/scsi.h
> > > @@ -429,4 +429,10 @@ #define SCSI_IOCTL_GET_BUS_NUMBER  0x5386
> > >  /* Used to obtain the PCI location of a device */
> > >  #define SCSI_IOCTL_GET_PCI             0x5387
> > >  
> > > +/* Pull a u32 out of a SCSI message (using BE SCSI conventions) */
> > > +static inline u32 scsi_to_u32(u8 *ptr)
> > > +{
> > > +       return (ptr[0]<<24) + (ptr[1]<<16) + (ptr[2]<<8) + ptr[3];
> > > +}
> > > +
> > >  #endif /* _SCSI_SCSI_H */ 
> > 
> > Please explain why it's necessary to export this to userspace.
> 
> Er it's not ... but then it's not necessary to export this entire file,
> either.

That's an acceptable answer, I suppose, given that glibc ships its own
copy of the file in question.

But it does contain ioctl definitions, and if we ever added any new
ioctls presumably they'd be added there too? It does seem to be the kind
of thing we _do_ want to export from the kernel, surely?


> From the SCSI point of view, the function definitely belongs in that
> file because it's an accessor to facilitate the processing of commands
> and their replies, which is what that file contains ... in fact it
> contains a lot of the internal mechanics of the SCSI layer that the user
> shouldn't necessarily be seeing.

All the more reason for us to export it for ourselves and exert some
editorial control, perhaps?

-- 
dwmw2

-
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/