Well, I'd argue that Berkeley defined a bunch of VFS attributes, and
then implemented them natively in UFS and LFS; other non-native
filesystems have to map their concepts of other file attributes (e.g.,
dates, permissions, etc.,) into the native VFS concepts.
Right. Except that
flink (make a new directory link for file given by descriptor),
flink() combined with the ability to create an unlinked file
in a given filesystem would allow for safe temporaries
without race conditions, that could be "published" when ready.
The System V people (Solaris, Unixware) call
On Mon, 28 Jun 1999, David S. Miller wrote:
Date: Mon, 28 Jun 1999 06:12:44 -0400 (EDT)
From: Alexander Viro [EMAIL PROTECTED]
3) openpromfs - sparc only (?), AFAICS not actively maintained.
Oh, it's maintained and used every day, believe me.
Cool ;-) There is a lot of
flink (make a new directory link for file given by descriptor),
flink() combined with the ability to create an unlinked file
in a given filesystem would allow for safe temporaries
without race conditions, that could be published when ready.
The System V people (Solaris, Unixware) call this
Bodo Rueskamp wrote:
flink (make a new directory link for file given by descriptor),
flink() combined with the ability to create an unlinked file
in a given filesystem would allow for safe temporaries
without race conditions, that could be published when ready.
The System V people
On Sun, 27 Jun 1999, Alexander Viro wrote:
On Mon, 28 Jun 1999, Doug Rabson wrote:
I'm talking about the concept of a header file containing something like:
#define FL_VFS 0
#define FL_FOOFS1
#define FD_BARFS2
...
not being scalable.
As far as sysctl goes, FreeBSD deprecates the use of numbers for OIDs and
has a string-based mechanism for exploring the sysctl tree.
So we are actually both going the same way. Linus with /proc/sys and his
official dislike of sysctl (Oh well I think sysctl using number spaces is the
right idea
On Mon, 28 Jun 1999, Alan Cox wrote:
As far as sysctl goes, FreeBSD deprecates the use of numbers for OIDs and
has a string-based mechanism for exploring the sysctl tree.
So we are actually both going the same way. Linus with /proc/sys and his
official dislike of sysctl (Oh well I think
On Mon, 28 Jun 1999, Alan Cox wrote:
As far as sysctl goes, FreeBSD deprecates the use of numbers for OIDs and
has a string-based mechanism for exploring the sysctl tree.
So we are actually both going the same way. Linus with /proc/sys and his
official dislike of sysctl (Oh well I think
As far as I know, only FreeBSD has a string-based sysctl implementation.
Nod.
Something which always confused me about Linux' procfs - what have all
these kernel variables got to do with process state? We used to have a
kernfs which was intended for this kind of thing but it rotted after
On Mon, 28 Jun 1999, Doug Rabson wrote:
As far as I know, only FreeBSD has a string-based sysctl implementation.
Something which always confused me about Linux' procfs - what have all
these kernel variables got to do with process state? We used to have a
Nothing. procfs is a union of 4
Date:Mon, 28 Jun 1999 06:12:44 -0400 (EDT)
From: Alexander Viro v...@math.psu.edu
3) openpromfs - sparc only (?), AFAICS not actively maintained.
Oh, it's maintained and used every day, believe me.
Later,
David S. Miller
da...@redhat.com
To Unsubscribe: send mail to
On Mon, 28 Jun 1999, David S. Miller wrote:
Date: Mon, 28 Jun 1999 06:12:44 -0400 (EDT)
From: Alexander Viro v...@math.psu.edu
3) openpromfs - sparc only (?), AFAICS not actively maintained.
Oh, it's maintained and used every day, believe me.
Cool ;-) There is a lot of
Something which always confused me about Linux' procfs - what have all
these kernel variables got to do with process state? We used to have a
kernfs which was intended for this kind of thing but it rotted after
people started extending sysctl for the purpose.
About as much as having a
On Mon, 28 Jun 1999, Francois-Rene Rideau wrote:
On Sun, Jun 27, 1999 at 12:58:05PM -0400, der Mouse wrote:
See NetBSD (and presumably other BSD) mount -o update,rdonly and/or
umount -f. (Last I tried, the latter didn't work as it should, but
that's a matter of fixing bugs rather than
Improving the Unix Kernels' API
A Kernel Discussion with Hacker Robert Ehrlich
Summary: after a discussion with R.E., I submit a suggestion about improving
the API of free Unices with useful features such as open(path,O_NULL);
Dear Free *n*x Kernel Hackers,
I've been
On Sun, 27 Jun 1999, Alexander Viro wrote:
On Sun, 27 Jun 1999, Doug Rabson wrote:
This looks viable as long as you don't use small integers to represent
FL_UFS etc. Having a single header defining constants for all filesystems
Erm... sizeof(int)==4. I doubt that you will
(clri didn't work?)
Never heard about clri (was under Linux).
May not have existed, then, which *would* explain it. :-)
Another problem was the ability to change the mount status of a
partition from read-write to read-only or to unmounted,
See NetBSD (and presumably other BSD) "mount -o
On Sun, 27 Jun 1999, der Mouse wrote:
(clri didn't work?)
Never heard about clri (was under Linux).
May not have existed, then, which *would* explain it. :-)
# debugfs -w /dev/sda1
debugfs: clri file
debugfs: close
It exists, all right ;-) Even documented - man 8 debugfs and there
Alexander Viro wrote:
asbestos underware[1]
BTW, how does NetBSD deal with HFS cough forks?
/asbestos underware
easy, it doesn't :-) we don't currently have HFS support, mainly b/c the
only freeware implementations of it (that i'm aware of) are GPL'd, and no
one has been able to devote
Improving the Unix Kernels' API
A Kernel Discussion with Hacker Robert Ehrlich
Summary: after a discussion with R.E., I submit a suggestion about improving
the API of free Unices with useful features such as open(path,O_NULL);
Dear Free *n*x Kernel Hackers,
I've been
.. but there remained one that garbled meta-data had made into a
non-existing block device, that would resist rm -f. He realized
that the device had an immutable attribute. However, the problem is
that to change the attribute, you have to open the file before you
can ioctl() on it;
BSD4.4
Francois-Rene Rideau wrote:
Robert told me that in some Unix flavors of old,
it was possible to open a file by path with a null access mode (O_NULL ?)
E.g. Linux. Very undocumented, but has been around for ages ('92 or
such). The main purpose is to keep the floppy drive from spinning up
to
On Sun, 27 Jun 1999, Bill Sommerfeld wrote:
.. but there remained one that garbled meta-data had made into a
non-existing block device, that would resist rm -f. He realized
that the device had an immutable attribute. However, the problem is
that to change the attribute, you have to
Usage of ioctl() on Linux was a bad idea and it's going to be fixed. More
or less in the same direction, not exactly the same - 4.4 chflags() works
fine for UFS and leaves other filesystems to map what they can into the
UFS set.
Which is bogus - immutable is not a UFS attribute, it's VFS
He realized that the device had an immutable attribute.
He tried to change the attribute with open() and ioctl()
As I think someone already mentioned, BSD has chflags(), which takes a
pathname.
Robert had to hand-remove the immutable flag
(I guess, by accessing the relevant block directly).
On Sun, 27 Jun 1999, Bill Sommerfeld wrote:
Usage of ioctl() on Linux was a bad idea and it's going to be fixed. More
or less in the same direction, not exactly the same - 4.4 chflags() works
fine for UFS and leaves other filesystems to map what they can into the
UFS set.
Which is
On Sun, 27 Jun 1999, Alexander Viro wrote:
On Sun, 27 Jun 1999, Bill Sommerfeld wrote:
Usage of ioctl() on Linux was a bad idea and it's going to be fixed. More
or less in the same direction, not exactly the same - 4.4 chflags() works
fine for UFS and leaves other filesystems to
Right. Except that UFS has not only generic attibutes. For example,
you have UF_NODUMP and SF_ARCHIVED. The *only* place in the /sys you
mention the former is sys/stat.h
Well, right, because backup/restore aren't part of the kernel...
(BTW, you don't even map it on EXT2_NODUMP_FL).
On Sun, 27 Jun 1999, Doug Rabson wrote:
This looks viable as long as you don't use small integers to represent
FL_UFS etc. Having a single header defining constants for all filesystems
Erm... sizeof(int)==4. I doubt that you will need more.
just doesn't scale at all.
Sure.
Alexander Viro wrote:
Proposed API on the Linux side being
int chflags(name, level, oldp, newp); where level is FL_VFS for generic
attirbutes (fs may map them on its own set) and FL_{UFS,EXT2,...} for raw
flags - corresponding filesystem is free to interpret the thing as it
likes and
On Sun, 27 Jun 1999, der Mouse wrote:
Another problem was the ability to change the mount status of a partition
from read-write to read-only or to unmounted,
See NetBSD (and presumably other BSD) mount -o update,rdonly and/or
umount -f. (Last I tried, the latter didn't work as it
On Sun, 27 Jun 1999, Jan-Simon Pendry wrote:
Alexander Viro wrote:
Proposed API on the Linux side being
int chflags(name, level, oldp, newp); where level is FL_VFS for generic
attirbutes (fs may map them on its own set) and FL_{UFS,EXT2,...} for raw
flags - corresponding
On Sun, 27 Jun 1999, der Mouse wrote:
# Robert had to hand-remove the immutable flag
# (I guess, by accessing the relevant block directly).
#
# (clri didn't work?)
Obviously the guy thinks along the lines that you need a file descriptor
to do things to files. That, or he didn't want to do an
On Sun, Jun 27, 1999 at 12:58:05PM -0400, der Mouse wrote:
As I think someone already mentioned, BSD has chflags(), [...]
Yup.
Robert had to hand-remove the immutable flag
(I guess, by accessing the relevant block directly).
(clri didn't work?)
Never heard about clri (was under Linux). And I
On Sun, 27 Jun 1999, Alexander Viro wrote:
On Sun, 27 Jun 1999, Doug Rabson wrote:
This looks viable as long as you don't use small integers to represent
FL_UFS etc. Having a single header defining constants for all filesystems
Erm... sizeof(int)==4. I doubt that you will need
(clri didn't work?)
Never heard about clri (was under Linux).
May not have existed, then, which *would* explain it. :-)
Another problem was the ability to change the mount status of a
partition from read-write to read-only or to unmounted,
See NetBSD (and presumably other BSD) mount -o
On Sun, Jun 27, 1999 at 07:33:32PM -0400, der Mouse wrote:
If you re-read the original message, the problem is what to do about
processes with open file descriptors on the partition [...]
Yes, that's the most difficult part. [...] NetBSD manpage:
-f The filesystem is forcibly
On Sun, 27 Jun 1999, der Mouse wrote:
(clri didn't work?)
Never heard about clri (was under Linux).
May not have existed, then, which *would* explain it. :-)
# debugfs -w /dev/sda1
debugfs: clri file
debugfs: close
It exists, all right ;-) Even documented - man 8 debugfs and there
On Sun, 27 Jun 1999 20:43:28 -0400 (EDT)
Alexander Viro v...@math.psu.edu wrote:
Forced revoke()? But then there is mmap() and IIRC revoke() on *BSD
doesn't unmap the stuff. Oh, shit, there is such thing as pending
unlink... Does vgone() force it?
It doesn't unmap the region, but it
On Mon, 28 Jun 1999, Doug Rabson wrote:
I'm talking about the concept of a header file containing something like:
#define FL_VFS 0
#define FL_FOOFS1
#define FD_BARFS2
...
not being scalable.
Do you have a complete list of filesystem
On Sun, 27 Jun 1999, Jason Thorpe wrote:
Regarding unlink()... those aren't operations on vnodes. Those are
operations on the filesystem namespace, and are thus (correctly)
unaffected.
Eh, wait. Those are operations on namespace, but at some moment you need
to clean the bit in inode
Alexander Viro wrote:
asbestos underware[1]
BTW, how does NetBSD deal with HFS cough forks?
/asbestos underware
easy, it doesn't :-) we don't currently have HFS support, mainly b/c the
only freeware implementations of it (that i'm aware of) are GPL'd, and no
one has been able to devote enough
On 27 Jun, Jason Thorpe wrote:
+-
| Alexander Viro v...@math.psu.edu wrote:
|doesn't unmap the stuff. Oh, shit, there is such thing as pending
|unlink... Does vgone() force it?
|
| Regarding unlink()... those aren't operations on vnodes. Those are
| operations on the filesystem
On Sun, 27 Jun 1999, Alexander Viro wrote:
As for the opening with no permissions - well, it would make *big* sense
if we could narrow down the API and move chown(), chmod(), etc. into libc
leaving f-variants in the kernel. Binary compatibility... Extreme variant
might include
On 27 Jun, To: thor...@nas.nasa.gov wrote:
+-
| (To which my own answer would be: deallocated on close as usual, no
| reason to treat this case specially that I know of.)
+---8
Strike that, I was on the wrong page. (Crossed threads re: general
revoke() on Linux)
--
brandon s. allbery
On Sun, 27 Jun 1999 allb...@ece.cmu.edu wrote:
On 27 Jun, Jason Thorpe wrote:
+-
| Alexander Viro v...@math.psu.edu wrote:
|doesn't unmap the stuff. Oh, shit, there is such thing as pending
|unlink... Does vgone() force it?
|
| Regarding unlink()... those aren't
-f The filesystem is forcibly unmounted. Active special devices
continue to work, but all other files return errors if further
accesses are attempted.
I think that returning errors is WRONG, unless [...]
It means that you can't fix the problem with the
48 matches
Mail list logo
