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 ?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/