From: Joe Thornber <joe@fib011235813.fsnet.co.uk>
To: Greg KH <greg@kroah.com>
Cc: Andrew Morton <akpm@digeo.com>,
lvm-devel@sistina.com, linux-kernel@vger.kernel.org
Subject: Re: dmfs for 2.5.51
Date: Fri, 13 Dec 2002 09:58:06 +0000 [thread overview]
Message-ID: <20021213095806.GC1117@reti> (raw)
In-Reply-To: <20021213052551.GB25099@kroah.com>
On Thu, Dec 12, 2002 at 09:25:51PM -0800, Greg KH wrote:
> On Thu, Dec 12, 2002 at 05:50:01PM -0800, Andrew Morton wrote:
> > hm. The whole thing seems hokey to me. Not sure why.
>
> I agree. It doesn't feel right. I mean, doing a mkdir(1) to create a
> device, which causes files to be created automagically in that
> directory? Something needs to change here, and I proposed a single file
> to write to that creates the device, but was shot down by the author.
Greg, I didn't mean to make it sound like I was shooting you down, I
just said that we'd leave it as it was for now. Having written the
code I wanted a bit more feedback. When I started writing the fs
interface a couple of people expressed concerns that I should try and
map things properly onto fs semantics and not just create a single
file. Given Andrews comment I guess I haven't done a good job. Could
you flesh out your single file idea a bit more please, there's a lot
of functionality to shoe horn in there.
> > > ...
> > > + echo -e "0 56 linear /dev/hda3 0\n56 102344 linear /dev/hda4 0" > table
> >
> > Maybe this is why.
>
> Heh, yeah, welcome to parsers in the kernel :)
> But the dm code today does much the same thing with ioctls, passing a
> string down to the loaded modules below it. So there is a bit of
> president. Even if it is ugly :)
y, the dm targets have always accepted their arguments as ascii
strings. So the file system interface just adds code to split the
input into lines, and then sscanf the first three elements of the line
- this is probably less code than the marshalling of binary data that
is done in the ioctl interface.
I see the fact that we're using ascii data as being the big advantage
of the fs interface, which neccessarily means doing a small amount of
parsing in kernel. You can't have things both ways.
> > > ...
> > > +static struct page *find_page(struct dmfs_file *f, loff_t len, int fill)
> >
> > This is called under spinlock.
> >
> > > ...
> > > + void *addr = (void *) __get_free_page(GFP_KERNEL);
> >
> > whoops.
My fault :(
> Nice catch. I'm not sure that the find_page(), __io() and friends
> functions are really needed at all.
It would be nice to get rid of them, what shall we replace them with ?
- Joe
next prev parent reply other threads:[~2002-12-13 9:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-13 1:26 dmfs for 2.5.51 Greg KH
[not found] ` <3DF93CC9.979CA988@digeo.com>
2002-12-13 5:25 ` Greg KH
2002-12-13 9:58 ` Joe Thornber [this message]
2002-12-13 17:32 ` Greg KH
2002-12-13 9:37 ` Joe Thornber
2002-12-13 17:29 ` Greg KH
2002-12-13 17:43 ` Joe Thornber
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=20021213095806.GC1117@reti \
--to=joe@fib011235813.fsnet.co.uk \
--cc=akpm@digeo.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lvm-devel@sistina.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox