Mark Kettenis <[EMAIL PROTECTED]> writes:
> Anyway, I agree with Marcus that it's useful to have this feature, and
> it's probably how Thomas designed it.
yep.
Thomas
> How about having a magic translator /dev/underlying to represent the
> underlying node of a translator (similar to /dev/tty for the
> controlling terminal)?
That would be a pain and not fit well with the abstraction layers.
There is no inherent mapping between processes and filesystems.
Mark Kettenis <[EMAIL PROTECTED]> writes:
> How about having a magic translator /dev/underlying to represent the
> underlying node of a translator (similar to /dev/tty for the
> controlling terminal)?
How would libc know about the underlying port? Remember, the
same process may be translating m
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Date: 14 Jul 2000 23:23:31 +0300
Mark Kettenis <[EMAIL PROTECTED]> writes:
>Date: Thu, 13 Jul 2000 19:27:55 -0400
>From: Olivier Galibert <[EMAIL PROTECTED]>
>
>settrans -c dummy /hurd/ext2fs `pwd`/dummy
>
>
Mark Kettenis <[EMAIL PROTECTED]> writes:
>Date: Thu, 13 Jul 2000 19:27:55 -0400
>From: Olivier Galibert <[EMAIL PROTECTED]>
>
>settrans -c dummy /hurd/ext2fs `pwd`/dummy
>
>...because the translator will end up looping on itself.
>
> Did you check that? If it really does that
Olivier Galibert <[EMAIL PROTECTED]> writes:
> It's probably even too magic for the translator itself. This does not
> work:
> dd if=/dev/zero of=dummy bs=1024k count=8
> mke2fs dummy
> settrans -c dummy /hurd/ext2fs `pwd`/dummy
>
> ...because the translator will end up looping on itself.
You
