LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: dushistov@mail.ru, linux-kernel@vger.kernel.org, sparc@gentoo.org
Subject: Re: [patch] export ufs_fs.h to userspace
Date: Thu, 8 Feb 2007 11:12:22 -0500	[thread overview]
Message-ID: <200702081112.23632.vapier@gentoo.org> (raw)
In-Reply-To: <1170950377.8675.60.camel@laptopd505.fenrus.org>

[-- 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 --]

  reply	other threads:[~2007-02-08 16:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08  7:46 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 [this message]
2007-02-08 20:02 ` Christoph Hellwig
2007-02-08 20:05   ` Mike Frysinger
2007-02-08 20:21     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200702081112.23632.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=arjan@infradead.org \
    --cc=dushistov@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparc@gentoo.org \
    --subject='Re: [patch] export ufs_fs.h to userspace' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).