[lkml]   [2007]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] export ufs_fs.h to userspace
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
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2007-02-08 17:15    [W:0.050 / U:2.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site