LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [patch] export ufs_fs.h to userspace
@ 2007-02-08  7:46 Mike Frysinger
  2007-02-08 10:33 ` Arjan van de Ven
  2007-02-08 20:02 ` Christoph Hellwig
  0 siblings, 2 replies; 9+ messages in thread
From: Mike Frysinger @ 2007-02-08  7:46 UTC (permalink / raw)
  To: dushistov; +Cc: linux-kernel, sparc

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

was ufs_fs.h purposefully not exported to userspace or did it just slip 
through the cracks ?  assuming the latter scenario, the attached patch 
touches up the relationship between ufs_fs.h and its sub headers (like 
ufs_fs_sb.h) so that we can export it ... the silo bootloader takes advantage 
of this header for example

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

---
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -324,6 +324,7 @@ unifdef-y += tty.h
 unifdef-y += types.h
 unifdef-y += udf_fs_i.h
 unifdef-y += udp.h
+unifdef-y += ufs_fs.h
 unifdef-y += uinput.h
 unifdef-y += uio.h
 unifdef-y += unistd.h
--- a/include/linux/ufs_fs.h
+++ b/include/linux/ufs_fs.h
@@ -45,8 +45,10 @@ typedef __u32 __bitwise __fs32;
 typedef __u16 __bitwise __fs16;
 #endif
 
+#ifdef __KERNEL__
 #include <linux/ufs_fs_i.h>
 #include <linux/ufs_fs_sb.h>
+#endif
 
 #define UFS_BBLOCK 0
 #define UFS_BBSIZE 8192
@@ -303,7 +305,7 @@ typedef __u16 __bitwise __fs16;
 #define UFS_MAXMNTLEN 512
 #define UFS2_MAXMNTLEN 468
 #define UFS2_MAXVOLLEN 32
-/* #define UFS_MAXCSBUFS 31 */
+#define UFS_MAXCSBUFS 31
 #define UFS_LINK_MAX 32000
 /*
 #define	UFS2_NOCSPTRS	((128 / sizeof(void *)) - 4)
--- a/include/linux/ufs_fs_sb.h
+++ b/include/linux/ufs_fs_sb.h
@@ -21,7 +21,6 @@
 struct ufs_sb_private_info;
 struct ufs_cg_private_info;
 struct ufs_csum;
-#define UFS_MAXCSBUFS 31
 
 struct ufs_sb_info {
 	struct ufs_sb_private_info * s_uspi;	

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] export ufs_fs.h to userspace
  2007-02-08  7:46 [patch] export ufs_fs.h to userspace Mike Frysinger
@ 2007-02-08 10:33 ` Arjan van de Ven
  2007-02-08 11:33   ` Alexey Dobriyan
  2007-02-08 15:10   ` Mike Frysinger
  2007-02-08 20:02 ` Christoph Hellwig
  1 sibling, 2 replies; 9+ messages in thread
From: Arjan van de Ven @ 2007-02-08 10:33 UTC (permalink / raw)
  To: Mike Frysinger; +Cc: dushistov, linux-kernel, sparc

On Thu, 2007-02-08 at 02:46 -0500, Mike Frysinger wrote:
> was ufs_fs.h purposefully not exported to userspace or did it just slip 
> through the cracks ?  assuming the latter scenario, the attached patch 
> touches up the relationship between ufs_fs.h and its sub headers (like 
> ufs_fs_sb.h) so that we can export it ... the silo bootloader takes advantage 
> of this header for example


are you sure it actually uses anything from this header, and not just
assumes the magic number to be there??
(also.. I kind of would think it reasonable for things with their own
UFS fs reader to have their own header)


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] export ufs_fs.h to userspace
  2007-02-08 10:33 ` Arjan van de Ven
@ 2007-02-08 11:33   ` Alexey Dobriyan
  2007-02-08 15:10   ` Mike Frysinger
  1 sibling, 0 replies; 9+ messages in thread
From: Alexey Dobriyan @ 2007-02-08 11:33 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Mike Frysinger, dushistov, linux-kernel, sparc

On 2/8/07, Arjan van de Ven <arjan@infradead.org> wrote:
> On Thu, 2007-02-08 at 02:46 -0500, Mike Frysinger wrote:
> > was ufs_fs.h purposefully not exported to userspace or did it just slip
> > through the cracks ?  assuming the latter scenario, the attached patch
> > touches up the relationship between ufs_fs.h and its sub headers (like
> > ufs_fs_sb.h) so that we can export it ... the silo bootloader takes
> advantage
> > of this header for example
>
>
> are you sure it actually uses anything from this header, and not just
> assumes the magic number to be there??
> (also.. I kind of would think it reasonable for things with their own
> UFS fs reader to have their own header)

ufs_fs.h certainly has things which certain types of userspace
programs could use:
on-disk layouts of UFS(2) inodes, cylinder groups, ... So it should be exported.

However, NAK patch in this form until all kernel internal things would
dissapear from
exported header: struct ufs_buffer_head, ufs_sb_private_info. Probably something
else, I haven't looked closely.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] export ufs_fs.h to userspace
  2007-02-08 10:33 ` Arjan van de Ven
  2007-02-08 11:33   ` Alexey Dobriyan
@ 2007-02-08 15:10   ` Mike Frysinger
  2007-02-08 15:59     ` Arjan van de Ven
  1 sibling, 1 reply; 9+ messages in thread
From: Mike Frysinger @ 2007-02-08 15:10 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: dushistov, linux-kernel, sparc

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

On Thursday 08 February 2007, Arjan van de Ven wrote:
> On Thu, 2007-02-08 at 02:46 -0500, Mike Frysinger wrote:
> > was ufs_fs.h purposefully not exported to userspace or did it just slip
> > through the cracks ?  assuming the latter scenario, the attached patch
> > touches up the relationship between ufs_fs.h and its sub headers (like
> > ufs_fs_sb.h) so that we can export it ... the silo bootloader takes
> > advantage of this header for example
>
> are you sure it actually uses anything from this header, and not just
> assumes the magic number to be there??
> (also.. I kind of would think it reasonable for things with their own
> UFS fs reader to have their own header)

silo utilizes the structures and the random defines so that it can query UFS 
filesystems directly
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] export ufs_fs.h to userspace
  2007-02-08 15:10   ` Mike Frysinger
@ 2007-02-08 15:59     ` Arjan van de Ven
  2007-02-08 16:12       ` Mike Frysinger
  0 siblings, 1 reply; 9+ messages in thread
From: Arjan van de Ven @ 2007-02-08 15:59 UTC (permalink / raw)
  To: Mike Frysinger; +Cc: dushistov, linux-kernel, sparc

On Thu, 2007-02-08 at 10:10 -0500, Mike Frysinger wrote:
> On Thursday 08 February 2007, Arjan van de Ven wrote:
> > On Thu, 2007-02-08 at 02:46 -0500, Mike Frysinger wrote:
> > > was ufs_fs.h purposefully not exported to userspace or did it just slip
> > > through the cracks ?  assuming the latter scenario, the attached patch
> > > touches up the relationship between ufs_fs.h and its sub headers (like
> > > ufs_fs_sb.h) so that we can export it ... the silo bootloader takes
> > > advantage of this header for example
> >
> > are you sure it actually uses anything from this header, and not just
> > assumes the magic number to be there??
> > (also.. I kind of would think it reasonable for things with their own
> > UFS fs reader to have their own header)
> 
> silo utilizes the structures and the random defines so that it can query UFS 
> filesystems directly

at which point arguably it should have it's own UFS header.
It's not using the UFS header to use as *kernel* interface!!

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] export ufs_fs.h to userspace
  2007-02-08 15:59     ` Arjan van de Ven
@ 2007-02-08 16:12       ` Mike Frysinger
  0 siblings, 0 replies; 9+ messages in thread
From: Mike Frysinger @ 2007-02-08 16:12 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: dushistov, linux-kernel, sparc

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

On Thursday 08 February 2007, Arjan van de Ven wrote:
> On Thu, 2007-02-08 at 10:10 -0500, Mike Frysinger wrote:
> > On Thursday 08 February 2007, Arjan van de Ven wrote:
> > > On Thu, 2007-02-08 at 02:46 -0500, Mike Frysinger wrote:
> > > > was ufs_fs.h purposefully not exported to userspace or did it just
> > > > slip through the cracks ?  assuming the latter scenario, the attached
> > > > patch touches up the relationship between ufs_fs.h and its sub
> > > > headers (like ufs_fs_sb.h) so that we can export it ... the silo
> > > > bootloader takes advantage of this header for example
> > >
> > > are you sure it actually uses anything from this header, and not just
> > > assumes the magic number to be there??
> > > (also.. I kind of would think it reasonable for things with their own
> > > UFS fs reader to have their own header)
> >
> > silo utilizes the structures and the random defines so that it can query
> > UFS filesystems directly
>
> at which point arguably it should have it's own UFS header.
> It's not using the UFS header to use as *kernel* interface!!

true, and i wont argue that point too much other than to say it's nice that 
the kernel provides it so as to reduce code duplication in the world

in more realistic terms, not exporting the ufs_fs.h header prevents any sort 
of raw filesystem checkers which would be running in userspace, but then 
again i cant quote any such packages that actually exist ;)

in the end, it doesnt really matter to me right now one way or the other as 
the silo guys do include some ufs code to handle the case where it is being 
built by a non-linux toolchain
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] export ufs_fs.h to userspace
  2007-02-08  7:46 [patch] export ufs_fs.h to userspace Mike Frysinger
  2007-02-08 10:33 ` Arjan van de Ven
@ 2007-02-08 20:02 ` Christoph Hellwig
  2007-02-08 20:05   ` Mike Frysinger
  1 sibling, 1 reply; 9+ messages in thread
From: Christoph Hellwig @ 2007-02-08 20:02 UTC (permalink / raw)
  To: Mike Frysinger; +Cc: dushistov, linux-kernel, sparc

On Thu, Feb 08, 2007 at 02:46:16AM -0500, Mike Frysinger wrote:
> was ufs_fs.h purposefully not exported to userspace or did it just slip 
> through the cracks ?  assuming the latter scenario, the attached patch 
> touches up the relationship between ufs_fs.h and its sub headers (like 
> ufs_fs_sb.h) so that we can export it ... the silo bootloader takes advantage 
> of this header for example

We should only export kernel interfaces and ufs_fs.h isn't one.  silo
wants it because it defines the ufs format - but the linux structs for
that can and do change, e.g. adding unions when we add support for the
gazillion+1st ufs format variant.  silo should just grab a copy of it
that it's happy with it and update it when it needs to support another
format variant (which I think is a rather theoretical issue as silo
only supports the solaris/sparc format IIR)


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] export ufs_fs.h to userspace
  2007-02-08 20:02 ` Christoph Hellwig
@ 2007-02-08 20:05   ` Mike Frysinger
  2007-02-08 20:21     ` Christoph Hellwig
  0 siblings, 1 reply; 9+ messages in thread
From: Mike Frysinger @ 2007-02-08 20:05 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: dushistov, linux-kernel, sparc

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On Thursday 08 February 2007, Christoph Hellwig wrote:
> On Thu, Feb 08, 2007 at 02:46:16AM -0500, Mike Frysinger wrote:
> > was ufs_fs.h purposefully not exported to userspace or did it just slip
> > through the cracks ?  assuming the latter scenario, the attached patch
> > touches up the relationship between ufs_fs.h and its sub headers (like
> > ufs_fs_sb.h) so that we can export it ... the silo bootloader takes
> > advantage of this header for example
>
> We should only export kernel interfaces and ufs_fs.h isn't one.  silo
> wants it because it defines the ufs format - but the linux structs for
> that can and do change, e.g. adding unions when we add support for the
> gazillion+1st ufs format variant.  silo should just grab a copy of it
> that it's happy with it and update it when it needs to support another
> format variant (which I think is a rather theoretical issue as silo
> only supports the solaris/sparc format IIR)

seems logical to mean, thanks for the response
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] export ufs_fs.h to userspace
  2007-02-08 20:05   ` Mike Frysinger
@ 2007-02-08 20:21     ` Christoph Hellwig
  0 siblings, 0 replies; 9+ messages in thread
From: Christoph Hellwig @ 2007-02-08 20:21 UTC (permalink / raw)
  To: Mike Frysinger; +Cc: Christoph Hellwig, dushistov, linux-kernel, sparc

On Thu, Feb 08, 2007 at 03:05:35PM -0500, Mike Frysinger wrote:
> > We should only export kernel interfaces and ufs_fs.h isn't one.  silo
> > wants it because it defines the ufs format - but the linux structs for
> > that can and do change, e.g. adding unions when we add support for the
> > gazillion+1st ufs format variant.  silo should just grab a copy of it
> > that it's happy with it and update it when it needs to support another
> > format variant (which I think is a rather theoretical issue as silo
> > only supports the solaris/sparc format IIR)
> 
> seems logical to mean, thanks for the response

Btw, if you're interesting in helping out in this area a little bit,
it would be nice if we could split up and move ufs_fs.h a little bit.
We should have an:

  fs/ufs/ufs.h for all driver internal declarations
  fs/ufs/ufs_layout.h that purely defines the layout can can be copied
                      directly into other tools that need the ufs layout
		      like silo

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2007-02-08 20:21 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-08  7:46 [patch] export ufs_fs.h to userspace Mike Frysinger
2007-02-08 10:33 ` Arjan van de Ven
2007-02-08 11:33   ` Alexey Dobriyan
2007-02-08 15:10   ` Mike Frysinger
2007-02-08 15:59     ` Arjan van de Ven
2007-02-08 16:12       ` Mike Frysinger
2007-02-08 20:02 ` Christoph Hellwig
2007-02-08 20:05   ` Mike Frysinger
2007-02-08 20:21     ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).