On Wed, Jul 29, 2009 at 04:37:36PM +0000, James Bottomley wrote: > On Wed, 2009-07-29 at 18:28 +0200, Sam Ravnborg wrote: > > On Wed, Jul 29, 2009 at 08:56:03AM -0500, James Bottomley wrote: > > > On Wed, 2009-07-29 at 14:11 +0300, Michael S. Tsirkin wrote: > > > > scsi/scsi.h is exported to userspace, so it should > > > > use __u8 instead of u8 as other userspace-visible headers do. > > > > > > Actually, can we just put a hold on this until we decide what we're > > > doing with exporting include/scsi. > > > > > > Arguments so far are > > > > > > 1. Don't export and let glibc supply the headers (as it does now) > > > 2. Move headers to be exported to include/linux > > > 3. Take over include/scsi export from glibc: this will necessitate > > > comparing our current headers and those of glibc and moving > > > stuff around. > > > > 2 + 3... > > Let include/scsi be kernel internal stuff. > > And have the exported headers in include/linux. > > I don't quite understand what you're saying here. I think 2 and 3 are > either/or options. Either we move the exported files to include/linux > or we export from include/scsi. That we should in any case look at what glibc have defined in their respective headers when we prepare the kernel versions for export. > > I have to say I don't like option 2 because the breakage is visible to > user level programs (unless we can persuade glibc people to #include > <linux/scsi.h> in scsi/scsi.h). We could turn this the other way around... glibc could add a wrapper file when they are ready to rely on the kernel version. So userspace continue to work independent of glibc using their own set of headers for scsi or they use the kernel supplied headers via the wrapper header file . Just an idea. It would be bad if userspace had to do something strange to pick up scsi.h in scsi/ for some glibc versions and from linux/ for other glibc versions. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
