Alexander Viro wrote:
>
> On Thu, 7 Jun 2001, Edgar Toernig wrote:
>
> > Alexander Viro wrote:
> > > ...
> > > dir = open("/usr/local", O_DIRECTORY);
> > > /* error handling */
> > > new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
> >
> > Do you really
On Thu, 7 Jun 2001, Edgar Toernig wrote:
> Alexander Viro wrote:
> > ...
> > dir = open("/usr/local", O_DIRECTORY);
> > /* error handling */
> > new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
>
> Do you really want to start using fds instead of
Alexander Viro wrote:
> ...
> dir = open("/usr/local", O_DIRECTORY);
> /* error handling */
> new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
Do you really want to start using fds instead of strings for tree
modifying commands (link, unlink, symlink,
Hi!
> > What I did was: add a field `char *mnt_symlink_prefix;' to the
> > struct vfsmount, fill it in super.c:add_vfsmnt(), use it in
> > namei.c:vfs_follow_link(). Pick the value up by recognizing
> > in super.c:do_mount() the option "symlink_prefix=&q
Hi!
What I did was: add a field `char *mnt_symlink_prefix;' to the
struct vfsmount, fill it in super.c:add_vfsmnt(), use it in
namei.c:vfs_follow_link(). Pick the value up by recognizing
in super.c:do_mount() the option symlink_prefix= before
giving the options to the separate
Alexander Viro wrote:
...
dir = open(/usr/local, O_DIRECTORY);
/* error handling */
new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
Do you really want to start using fds instead of strings for tree
modifying commands (link, unlink, symlink, rename,
On Thu, 7 Jun 2001, Edgar Toernig wrote:
Alexander Viro wrote:
...
dir = open(/usr/local, O_DIRECTORY);
/* error handling */
new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
Do you really want to start using fds instead of strings for tree
Alexander Viro wrote:
On Thu, 7 Jun 2001, Edgar Toernig wrote:
Alexander Viro wrote:
...
dir = open(/usr/local, O_DIRECTORY);
/* error handling */
new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
Do you really want to start using
In article <[EMAIL PROTECTED]>,
Hank Leininger <[EMAIL PROTECTED]> writes:
> On 2001-06-03, [EMAIL PROTECTED] wrote:
>
>> Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
>> /, /usr and /usr/spool filesystems for FOO OS. Now
>>
Alexander Viro writes:
> leaves ncp with its ioctls ugliness.
Authentication will be ugly. Joe mounts a filesystem, and does
not bother to authenticate. He gets world-accessible files.
Then Kevin authenticates as himself, and later as db_adm too.
Along comes Sue, who can authenticate the whole
On Sun, Jun 03, 2001 at 07:25:25AM -0400, Alexander Viro wrote:
> BTW, bind and friends are also easy - it's
> what = open(old, 0);
> where = open(mountpoint, 0);
> new_mount(where, MNT_BIND, what);
>
> Comments?
What if `what' and or `where' aren't directories but e.g.
> Current interface had grown an impressive collection of warts.
> Worse yet, you _can't_ put parsing into generic code.
> There are filesystems that have a binary object as 'data'.
Yes, that was a very unfortunate decision, back in the good old times
when nfs was implemented. And smb, ncp, coda
On 2001-06-03, [EMAIL PROTECTED] wrote:
> Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
> /, /usr and /usr/spool filesystems for FOO OS. Now
> mount /dev/a /mnt -o symlink_prefix=/mnt
> mount /dev/b /mnt/usr -o symlink_prefix=/mnt
> mount
From [EMAIL PROTECTED] Sun Jun 3 13:25:31 2001
> [One could start a subdiscussion about that part.
> The mount(2) system call needs to transport vfs information
> and per-fs information. So far, the vfs information used
> flag bits only, but sooner or later we'll want to
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:
> What I did was: add a field `char *mnt_symlink_prefix;' to the
> struct vfsmount, fill it in super.c:add_vfsmnt(), use it in
> namei.c:vfs_follow_link(). Pick the value up by recognizing
> in super.c:do_mount() the option "symlin
> We can kludge around anything. The question being, what for?
> It still leaves ncp with its ioctls ugliness.
I show how to simplify the kernel source without changing the
interface. That is good, and there are some free benefits.
You want to design a new interface. Maybe that is good as well,
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:
> > Current interface had grown an impressive collection of warts.
> > Worse yet, you _can't_ put parsing into generic code.
> > There are filesystems that have a binary object as 'data'.
>
> Yes, that was a very unfortunate decision, back in the
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:
> [My version: keep interface constant, reorganize kernel source
> to do certain things in one place instead of in several places.
> Advantage: treatment becomes uniform and some options that make sense
> for all filesystem types but are available
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:
[My version: keep interface constant, reorganize kernel source
to do certain things in one place instead of in several places.
Advantage: treatment becomes uniform and some options that make sense
for all filesystem types but are available today
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:
Current interface had grown an impressive collection of warts.
Worse yet, you _can't_ put parsing into generic code.
There are filesystems that have a binary object as 'data'.
Yes, that was a very unfortunate decision, back in the good old
We can kludge around anything. The question being, what for?
It still leaves ncp with its ioctls ugliness.
I show how to simplify the kernel source without changing the
interface. That is good, and there are some free benefits.
You want to design a new interface. Maybe that is good as well,
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:
What I did was: add a field `char *mnt_symlink_prefix;' to the
struct vfsmount, fill it in super.c:add_vfsmnt(), use it in
namei.c:vfs_follow_link(). Pick the value up by recognizing
in super.c:do_mount() the option symlink_prefix= before
From [EMAIL PROTECTED] Sun Jun 3 13:25:31 2001
[One could start a subdiscussion about that part.
The mount(2) system call needs to transport vfs information
and per-fs information. So far, the vfs information used
flag bits only, but sooner or later we'll want to have
On Sun, Jun 03, 2001 at 07:25:25AM -0400, Alexander Viro wrote:
BTW, bind and friends are also easy - it's
what = open(old, 0);
where = open(mountpoint, 0);
new_mount(where, MNT_BIND, what);
Comments?
What if `what' and or `where' aren't directories but e.g. sockets?
Current interface had grown an impressive collection of warts.
Worse yet, you _can't_ put parsing into generic code.
There are filesystems that have a binary object as 'data'.
Yes, that was a very unfortunate decision, back in the good old times
when nfs was implemented. And smb, ncp, coda
On 2001-06-03, [EMAIL PROTECTED] wrote:
Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
/, /usr and /usr/spool filesystems for FOO OS. Now
mount /dev/a /mnt -o symlink_prefix=/mnt
mount /dev/b /mnt/usr -o symlink_prefix=/mnt
mount /dev/c /mnt/usr/spool
Alexander Viro writes:
leaves ncp with its ioctls ugliness.
Authentication will be ugly. Joe mounts a filesystem, and does
not bother to authenticate. He gets world-accessible files.
Then Kevin authenticates as himself, and later as db_adm too.
Along comes Sue, who can authenticate the whole
In article [EMAIL PROTECTED],
Hank Leininger [EMAIL PROTECTED] writes:
On 2001-06-03, [EMAIL PROTECTED] wrote:
Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
/, /usr and /usr/spool filesystems for FOO OS. Now
mount /dev/a /mnt -o symlink_prefix=/mnt
ilesystem should be
> regarded as pointing to /mnt/foo/bar.
>
> Since doing ls -ld on every component of every pathname was
> far too slow, I made a small kernel wart, where a mount option
> -o symlink_prefix=/pathname would cause /pathname to be prepended
>
should be
regarded as pointing to /mnt/foo/bar.
Since doing ls -ld on every component of every pathname was
far too slow, I made a small kernel wart, where a mount option
-o symlink_prefix=/pathname would cause /pathname to be prepended
in front of every absolute symlink
Alexander Viro wrote:
> I can see how to implement per-mountpoint variant. However, I'm
> less than enthusiastic about the API side of that and about the
> ugliness it will lead to. It smells like a wrong approach. And
> no, I don't see a good one right now.
Aren't we one day going to have
> Since doing ls -ld on every component of every pathname was
> far too slow, I made a small kernel wart, where a mount option
> -o symlink_prefix=/pathname would cause /pathname to be prepended
> in front of every absolute symlink in the given filesystem
> (when the symlink is follow
/mnt/foo/bar.
>
> Since doing ls -ld on every component of every pathname was
> far too slow, I made a small kernel wart, where a mount option
> -o symlink_prefix=/pathname would cause /pathname to be prepended
> in front of every absolute symlink in the given filesystem
> (when the sy
, I made a small kernel wart, where a mount option
-o symlink_prefix=/pathname would cause /pathname to be prepended
in front of every absolute symlink in the given filesystem
(when the symlink is followed). That works satisfactorily.
Remain the questions:
(i) is there already a mechanism
, I made a small kernel wart, where a mount option
-o symlink_prefix=/pathname would cause /pathname to be prepended
in front of every absolute symlink in the given filesystem
(when the symlink is followed). That works satisfactorily.
Remain the questions:
(i) is there already a mechanism
doing ls -ld on every component of every pathname was
far too slow, I made a small kernel wart, where a mount option
-o symlink_prefix=/pathname would cause /pathname to be prepended
in front of every absolute symlink in the given filesystem
(when the symlink is followed). That works
on every component of every pathname was
far too slow, I made a small kernel wart, where a mount option
-o symlink_prefix=/pathname would cause /pathname to be prepended
in front of every absolute symlink in the given filesystem
(when the symlink is followed). That works satisfactorily
Alexander Viro wrote:
I can see how to implement per-mountpoint variant. However, I'm
less than enthusiastic about the API side of that and about the
ugliness it will lead to. It smells like a wrong approach. And
no, I don't see a good one right now.
Aren't we one day going to have stackable
38 matches
Mail list logo
