Re: [PATCH] reiserfs: fix handling of device names with /'s in them

[Hans Reiser]

Jeffrey Mahoney wrote:

> Hans Reiser wrote:
>
> >Jeff Mahoney wrote:
>
> >>Hans Reiser wrote:
> >>
> >>
> >>Hans, we're all in agreement that we'd prefer drivers not use names with
> >>slashes in them,
>
> >there is nothing wrong with using names that have slashes.  The thing
> >that is wrong is somehow needing to translate them into names with
> "!"'s.
>
>
> If using something with slashes in it as a file name component isn't
> problematic, then by all means create a single file system object named
> "a/b" where "a" doesn't refer to a parent directory and tell us all how.

Create a mountpoint which knows how to resolve a/b without using a
"directory".

>
> >>and it would be nice to correct drivers currently using
> >>them. The problem is that when you change the name of a device, that's a
> >>userspace visible change.
>
> >So don't.  Why would user space care how you parse it and whether the
> >driver or reiserfs does it?
>
>
> Huh? The block device's name is exported directly via /proc/partitions,
> but then also used as a file name component in sysfs, and also procfs
> via reiserfs. How do you propose fixing this without adding an
> additional field to genhd? Adding a helper function is essentially the
> same thing as this patch other than it being open coded,

what is open coding?  Something different from free software?

> and I'm not
> getting the impression that the open coding is your issue.
>
> >>Scripts that currently expect, say,
> >>/proc/partitions to contain cciss/<number> will break between kernel
> >>versions. Sysfs wants to use the device name as a pathname component,
> >>and as such translates the / to a !, the same as this patch proposes.
> >>
> >>Reiserfs gets involved because it expects that name to be usable as a
> >>file system pathname component when it is not intended to be one without
> >> translating slashes into another character. The difference is that
> >>block device names are allowed to have slashes in them, while normal
> >>file system names are not.
>
> >We should distinguish here between names and name components.
>
>
> In terms of file system names, I have been making that distinction. In
> terms of block devices, the name

the name refers to?

> consists of only one component.

So fix that.  Create a pseudo directory, and have a/b and a/c get
resolved by a.

That is cleaner than converting  / to !.

> More below.
>
> >>The fact is that device driver names, when in
> >>/dev can use separate components, like /dev/cciss/0, but when used in
> >>the manner reiserfs wants them to be used, they can't. Also, I'm not
> >>talking about name spaces like struct namespace, I mean that the group
> >>of names that block device drivers use have different constraints than
> >>the group of names that are allowable as file names.
> >>
> >>The fact is that this change is required for users deploying devices
> >>that use slashes in their names to see the proc data for a reiserfs file
> >>system. You can point the finger all you want at the block drivers in
> >>the mean time, but it's still a reiserfs problem.
>
> >I still do not grok why you need to change / to !.
>
> >Something is wrong.  Reiserfs is being asked to do something that
> >somebody else should be doing.
>
>
> Splitting the block device names with / is applying file system path
> name rules to the block device name, when they don't.

Don't what?

> The entire point
> of this is that "cciss/whatever" refers to a single object in the block
> layer, but when you apply file system rules, it becomes two.

Uh, no, a/b in any POSIX filesystem refers to one object.  Now maybe
someday....  probably not what you meant....

> This is not
> the desired interpretation, which is why we need to replace the pathname
> separator in the name. ReiserFS is the component that is choosing to use
> the block device name as a pathname component and is responsible for
> making any translation to that usage.

This makes no sense.  I have the feeling you see trees and I see forest.

>
> -Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/