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 strin
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, ren
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=&quo
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 b
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
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, 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 "s
> 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 goo
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 tod
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
>
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 stacka
> 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 that
19 matches
Mail list logo
