> > 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. Exce
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 rath
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 rathe
> > 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
> > 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
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 l
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.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: sen
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
On Mon, 28 Jun 1999, David S. Miller wrote:
>Date: Mon, 28 Jun 1999 06:12:44 -0400 (EDT)
>From: Alexander Viro
>
>3) openpromfs - sparc only (?), AFAICS not actively maintained.
>
> Oh, it's maintained and used every day, believe me.
Cool ;-) There is a lot of stuff that is
Date:Mon, 28 Jun 1999 06:12:44 -0400 (EDT)
From: Alexander Viro
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 majord...@freebsd.org
with
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 f
> 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, 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
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 t
> 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 id
> 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 ide
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
> > ...
> >
> >
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
> > ...
> >
> > n
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 Sys
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 Syst
> >> 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) ca
> >> 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) cal
>> -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
On Sun, 27 Jun 1999 allb...@ece.cmu.edu wrote:
> On 27 Jun, Jason Thorpe wrote:
> +-
> | Alexander Viro 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 vno
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, 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 {set,get}
On 27 Jun, Jason Thorpe wrote:
+-
| Alexander Viro 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 namespace, and a
Alexander Viro wrote:
> [1]
> BTW, how does NetBSD deal with HFS forks?
>
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 time to it to get a BSD-licensed
versi
Alexander Viro wrote:
> [1]
> BTW, how does NetBSD deal with HFS forks?
>
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 time to it to get a BSD-licensed
versio
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 bit
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 bitm
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 fi
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 fil
On Sun, 27 Jun 1999 20:43:28 -0400 (EDT)
Alexander Viro <[EMAIL PROTECTED]> 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 Sun, 27 Jun 1999 20:43:28 -0400 (EDT)
Alexander Viro 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 doesn't allow any m
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 t
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 th
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 u
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 un
>> (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) "m
>> (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) "mo
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
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
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). A
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 a
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 - correspondin
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 a
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
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
> 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, 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 file
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.
>
> >
> 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
> 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 VF
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 hav
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 che
> .. 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;
BSD
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
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 d
59 matches
Mail list logo
