Daniel Phillips wrote:
> Graciously accepted. Coming up with something sensible in a mere 6
> months would be a minor miracle. ;-)
>
> - what happens if the user forgets to close the transaction?
then the user has branched into his own version, or at least that would be my
take on it.
Daniel Phillips wrote:
Graciously accepted. Coming up with something sensible in a mere 6
months would be a minor miracle. ;-)
- what happens if the user forgets to close the transaction?
then the user has branched into his own version, or at least that would be my
take on it. Another
Daniel Phillips <[EMAIL PROTECTED]> said:
> On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
[...]
> > you break UNIX fundamentals. But I'm quite relieved now because I'm
> > pretty sure that something like that will never go into the kernel.
> OK, I'll take that as "I couldn't find a piece
Daniel Phillips [EMAIL PROTECTED] said:
On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
[...]
you break UNIX fundamentals. But I'm quite relieved now because I'm
pretty sure that something like that will never go into the kernel.
OK, I'll take that as I couldn't find a piece of code
On Sun, May 27, 2001 at 10:45:17PM +0200, Daniel Phillips wrote:
> On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
> > Daniel Phillips wrote:
> > > I'm not claiming there isn't breakage somewhere,
> >
> > you break UNIX fundamentals. But I'm quite relieved now because I'm
> > pretty sure that
On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > It won't, the open for "." is handled in the VFS, not the
> > filesystem - it will open the directory. (Without needing to be
> > told it's a directory via O_DIRECTORY.) If you do open("magicdev")
> > you'll get the
Daniel Phillips wrote:
>
> It won't, the open for "." is handled in the VFS, not the filesystem -
> it will open the directory. (Without needing to be told it's a
> directory via O_DIRECTORY.) If you do open("magicdev") you'll get the
> device, because that's handled by magicdevfs.
You really
Daniel Phillips wrote:
It won't, the open for . is handled in the VFS, not the filesystem -
it will open the directory. (Without needing to be told it's a
directory via O_DIRECTORY.) If you do open(magicdev) you'll get the
device, because that's handled by magicdevfs.
You really mean
On Sun, May 27, 2001 at 10:45:17PM +0200, Daniel Phillips wrote:
On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
Daniel Phillips wrote:
I'm not claiming there isn't breakage somewhere,
you break UNIX fundamentals. But I'm quite relieved now because I'm
pretty sure that something
On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
Daniel Phillips wrote:
It won't, the open for . is handled in the VFS, not the
filesystem - it will open the directory. (Without needing to be
told it's a directory via O_DIRECTORY.) If you do open(magicdev)
you'll get the device,
On Saturday 26 May 2001 05:07, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > Oops, oh wait, there's already another open point: your breakage
> > examples both rely on opening ".". You're right, "." should always
> > be a directory and I believe that's enforced by the VFS. So we
> > don't
On Saturday 26 May 2001 05:07, Edgar Toernig wrote:
Daniel Phillips wrote:
Oops, oh wait, there's already another open point: your breakage
examples both rely on opening .. You're right, . should always
be a directory and I believe that's enforced by the VFS. So we
don't have an
Daniel Phillips wrote:
>
> Oops, oh wait, there's already another open point: your breakage
> examples both rely on opening ".". You're right, "." should always be
> a directory and I believe that's enforced by the VFS. So we don't have
> an example of breakage yet.
That's just because I did
On Thursday 24 May 2001 22:59, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > > > Readdir fills in a directory type, so ls sees it as a directory
> > > > and does the right thing. On the other hand, we know we're on
> > > > a device filesystem so we will next open the name as a regular
> > >
On Friday 25 May 2001 00:00, Hans Reiser wrote:
> Daniel Phillips wrote:
> > I suppose I'm just reiterating the obvious, but we should
> > eventually have a generic filesystem transaction API at the VFS
> > level, once we have enough data points to know what the One True
> > API should be.
>
>
On Friday 25 May 2001 00:00, Hans Reiser wrote:
Daniel Phillips wrote:
I suppose I'm just reiterating the obvious, but we should
eventually have a generic filesystem transaction API at the VFS
level, once we have enough data points to know what the One True
API should be.
Daniel,
On Thursday 24 May 2001 22:59, Edgar Toernig wrote:
Daniel Phillips wrote:
Readdir fills in a directory type, so ls sees it as a directory
and does the right thing. On the other hand, we know we're on
a device filesystem so we will next open the name as a regular
file, and find
Daniel Phillips wrote:
Oops, oh wait, there's already another open point: your breakage
examples both rely on opening .. You're right, . should always be
a directory and I believe that's enforced by the VFS. So we don't have
an example of breakage yet.
That's just because I did a simple
Daniel Phillips wrote:
>
> On Tuesday 22 May 2001 22:10, Andreas Dilger wrote:
> > Peter Braam writes:
> > > File system journal recovery can corrupt a snapshot, because it
> > > copies data that needs to be preserved in a snapshot. During
> > > journal replay such data may be copied again, but
On Thu, 24 May 2001, Edgar Toernig wrote:
> > What *won't* happen is, you won't get side effects from opening
> > your serial ports (you'd have to open them without O_DIRECTORY
> > to get that) so that seems like a little step forward.
>
> As already said: depending on O_DIRECTORY breaks
On Tuesday 22 May 2001 22:10, Andreas Dilger wrote:
> Peter Braam writes:
> > File system journal recovery can corrupt a snapshot, because it
> > copies data that needs to be preserved in a snapshot. During
> > journal replay such data may be copied again, but the source can
> > have new data
On Thursday 24 May 2001 02:23, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > > > It's going to be marked 'd', it's a directory, not a file.
> > >
> > > Aha. So you lose the S_ISCHR/BLK attribute.
> >
> > Readdir fills in a directory type, so ls sees it as a directory and
> > does the right
[cc list reduced]
Andreas Dilger writes:
> PS - I used to think shrinking a filesystem online was useful, but there
> are a huge amount of problems with this and very few real-life
> benefits, as long as you can at least do offline shrinking. With
> proper LVM usage, the need to
[cc list reduced]
Andreas Dilger writes:
PS - I used to think shrinking a filesystem online was useful, but there
are a huge amount of problems with this and very few real-life
benefits, as long as you can at least do offline shrinking. With
proper LVM usage, the need to
Daniel Phillips wrote:
On Tuesday 22 May 2001 22:10, Andreas Dilger wrote:
Peter Braam writes:
File system journal recovery can corrupt a snapshot, because it
copies data that needs to be preserved in a snapshot. During
journal replay such data may be copied again, but the source
On Thu, 24 May 2001, Edgar Toernig wrote:
What *won't* happen is, you won't get side effects from opening
your serial ports (you'd have to open them without O_DIRECTORY
to get that) so that seems like a little step forward.
As already said: depending on O_DIRECTORY breaks POSIX
On Thursday 24 May 2001 02:23, Edgar Toernig wrote:
Daniel Phillips wrote:
It's going to be marked 'd', it's a directory, not a file.
Aha. So you lose the S_ISCHR/BLK attribute.
Readdir fills in a directory type, so ls sees it as a directory and
does the right thing. On the
On Tuesday 22 May 2001 22:10, Andreas Dilger wrote:
Peter Braam writes:
File system journal recovery can corrupt a snapshot, because it
copies data that needs to be preserved in a snapshot. During
journal replay such data may be copied again, but the source can
have new data already.
Daniel Phillips wrote:
> On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
> > Daniel Phillips wrote:
> > > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > > > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > > > > What I'd
On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > > > What I'd like to see:
> > > > >
> > > > > -
On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
> IMO the whole idea of arguments following the device name is junk
> (incl a "/ctrl").
You know I didn't suggest that, right? I find it pretty strange too, but
I'm listening to hear the technical arguments.
> Just think about the
On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
Daniel Phillips wrote:
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
On Mon, 21 May 2001, Daniel Phillips wrote:
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see:
- An interface for
Daniel Phillips wrote:
On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
Daniel Phillips wrote:
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
On Mon, 21 May 2001, Daniel Phillips wrote:
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see:
On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
IMO the whole idea of arguments following the device name is junk
(incl a /ctrl).
You know I didn't suggest that, right? I find it pretty strange too, but
I'm listening to hear the technical arguments.
Just think about the implications of
On Wed, 23 May 2001, Edgar Toernig wrote:
> And with special "ctrl" devices (ie /dev/ttyS0 and /dev/ttyS0ctrl):
> This _may_ work for some kind of devices. But serial ports are one
> example where it simply will _not_. It requires that you know the
That's quite funny, you know...
Daniel Phillips wrote:
>
> On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > > What I'd like to see:
> > > >
> > > > - An interface for registering an array of related devices
> > > >
Andreas,
I think that the issue is something different. Suppose the snapshot has
been created. I know that this can be done safely with the API's you
allude to. Life goes on and the journal FS keeps changing the file system
and if the system doesn't crash, everything is fine: blocks get
On Tuesday 22 May 2001 19:49, Oliver Xymoron wrote:
> On Tue, 22 May 2001, Daniel Phillips wrote:
> > > I don't think it's likely to be even workable. Just consider the
> > > directory entry for a moment - is it going to be marked d or
> > > [cb]?
> >
> > It's going to be marked 'd', it's a
On Tue, 22 May 2001, Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Andreas Dilger wrote: Actually, the LVM snapshot
> interface has (optional) hooks into the filesystem to ensure that it
> is consistent at the time the snapshot is created.
But I think that LVM is implemented "the wrong way
On Tue, 22 May 2001, Andreas Dilger wrote:
>
> Actually, the LVM snapshot interface has (optional) hooks into the filesystem
> to ensure that it is consistent at the time the snapshot is created.
Note that this is still fundamentally a broken interface: the filesystem
may not _have_ a block
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> On Mon, 21 May 2001, Daniel Phillips wrote:
> > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > What I'd like to see:
> > >
> > > - An interface for registering an array of related devices
> > > (almost always two: raw and ctl) and
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> What I'd like to see:
>
> - An interface for registering an array of related devices (almost
> always two: raw and ctl) and their legacy device numbers with a
> single userspace callout that does whatever /dev/ creation needs to
> be done.
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
On Mon, 21 May 2001, Daniel Phillips wrote:
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see:
- An interface for registering an array of related devices
(almost always two: raw and ctl) and their legacy
On Wed, 23 May 2001, Edgar Toernig wrote:
And with special ctrl devices (ie /dev/ttyS0 and /dev/ttyS0ctrl):
This _may_ work for some kind of devices. But serial ports are one
example where it simply will _not_. It requires that you know the
That's quite funny, you know...
Daniel Phillips wrote:
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
On Mon, 21 May 2001, Daniel Phillips wrote:
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see:
- An interface for registering an array of related devices
(almost always two:
On Tue, 22 May 2001, Andreas Dilger wrote:
Actually, the LVM snapshot interface has (optional) hooks into the filesystem
to ensure that it is consistent at the time the snapshot is created.
Note that this is still fundamentally a broken interface: the filesystem
may not _have_ a block
On Tue, 22 May 2001, Linus Torvalds wrote:
On Tue, 22 May 2001, Andreas Dilger wrote: Actually, the LVM snapshot
interface has (optional) hooks into the filesystem to ensure that it
is consistent at the time the snapshot is created.
But I think that LVM is implemented the wrong way
Andreas,
I think that the issue is something different. Suppose the snapshot has
been created. I know that this can be done safely with the API's you
allude to. Life goes on and the journal FS keeps changing the file system
and if the system doesn't crash, everything is fine: blocks get
On Tuesday 22 May 2001 19:49, Oliver Xymoron wrote:
On Tue, 22 May 2001, Daniel Phillips wrote:
I don't think it's likely to be even workable. Just consider the
directory entry for a moment - is it going to be marked d or
[cb]?
It's going to be marked 'd', it's a directory, not a
Hi!
> Yes, and that is exactly the difference between having a side effect
> on the open(2), versus having the effect as a result of a write(2).
>
> Unfortunately, there are already some cases where an open
> on a device can have unexpected results. If you don't want
> to get blocked waiting
Hi!
> A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a
> no-op. Breaking that assumption is a Bad Thing(tm).
Then we have a problem. Just opening /dev/ttyS0 currently *has* side
effects (it is visible on modem lines from serial port; it can block
you forever).
If this
Hi!
> So I guess things have already been a bit messy in this
> area for many years, even before linux even existed, and
> in some cases you can't really do anything about it because
> the behaviour is mandated by the applicable standards, like
> POSIX, SUS, or whatever.
> (The blocking of the
On Mon, 21 May 2001, David Lang wrote:
> what makes you think it's safe to say there's only one floppy drive?
Read as: it doesn't make sense to have per-fd state on a single floppy
device given that there's only one actual hardware instance associated
with it and multiple openers don't make
On Sat, 19 May 2001, Jeff Garzik wrote:
> Why are LVM and EVMS(competing LVM project) needed at all?
>
> Surely the same can be accomplished with
> * md
> * snapshot blkdev (attached in previous e-mail)
> * giving partitions and blkdevs the ability to grow and shrink
> * giving filesystems the
On Sat, 19 May 2001, Alexander Viro wrote:
> Let's distinguish between per-fd effects (that's what name in
> open(name, flags) is for - you are asking for descriptor and telling
> what behaviour do you want for IO on it) and system-wide side effects.
>
> IMO encoding the former into name is
On Mon, 21 May 2001, David Lang wrote:
what makes you think it's safe to say there's only one floppy drive?
Read as: it doesn't make sense to have per-fd state on a single floppy
device given that there's only one actual hardware instance associated
with it and multiple openers don't make
On Sat, 19 May 2001, Jeff Garzik wrote:
Why are LVM and EVMS(competing LVM project) needed at all?
Surely the same can be accomplished with
* md
* snapshot blkdev (attached in previous e-mail)
* giving partitions and blkdevs the ability to grow and shrink
* giving filesystems the ability
Hi!
So I guess things have already been a bit messy in this
area for many years, even before linux even existed, and
in some cases you can't really do anything about it because
the behaviour is mandated by the applicable standards, like
POSIX, SUS, or whatever.
(The blocking of the open on
On Sat, 19 May 2001, Alexander Viro wrote:
Let's distinguish between per-fd effects (that's what name in
open(name, flags) is for - you are asking for descriptor and telling
what behaviour do you want for IO on it) and system-wide side effects.
IMO encoding the former into name is perfectly
Hi!
Yes, and that is exactly the difference between having a side effect
on the open(2), versus having the effect as a result of a write(2).
Unfortunately, there are already some cases where an open
on a device can have unexpected results. If you don't want
to get blocked waiting for the
Hi!
A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a
no-op. Breaking that assumption is a Bad Thing(tm).
Then we have a problem. Just opening /dev/ttyS0 currently *has* side
effects (it is visible on modem lines from serial port; it can block
you forever).
If this
Here's a dumb question, and I apologize if I am questioning computer
science dogma...
Why are LVM and EVMS(competing LVM project) needed at all?
Surely the same can be accomplished with
* md
* snapshot blkdev (attached in previous e-mail)
* giving partitions and blkdevs the ability to grow and
Linus Torvalds wrote:
> There are some strong arguments that we should have filesystem
> "backdoors" for maintenance purposes, including backup.
I think I agree with something Al said over IRC, that fs-level snapshots
are preferred over block level snapshots.
fs-level snapshots should become
On Sat, 19 May 2001, Alexander Viro wrote:
>
> On Sun, 20 May 2001, Edgar Toernig wrote:
>
> > That assumption is totally bogus. Even for regular files you have side
> > effects (atime); for anything else they're unpredictable.
>
> That means only one thing: safe backups are possible only in
On Sun, 20 May 2001, Edgar Toernig wrote:
> That assumption is totally bogus. Even for regular files you have side
> effects (atime); for anything else they're unpredictable.
That means only one thing: safe backups are possible only in single-user
mode. For values of safe being "not
nitpicking: a system call without side effects would be pretty useless.
Alexander Viro wrote:
> A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a
> no-op. Breaking that assumption is a Bad Thing(tm).
That assumption is totally bogus. Even for regular files you have side
On Sat, 19 May 2001, Jeff Garzik wrote:
> Are we talking about device arguments just for chrdevs and blkdevs?
> (ie. drivers) or for regular files too?
Let's distinguish between per-fd effects (that's what name in open(name, flags)
is for - you are asking for descriptor and telling what
Jeff Garzik wrote:
> Notice also a "metadata miscdev" solves the problem of passing options
> on open -- just pass those options to the miscdev before you open it...
to be more clear, "it" == the data device, not the metadata miscdev
--
Jeff Garzik | "Do you have to make light of
Are we talking about device arguments just for chrdevs and blkdevs?
(ie. drivers) or for regular files too?
Speaking about drivers specifically, a controlling miscdev, one per
device or one per group of devices depending on your needs, is a much
more clean solution for passing ioctl-type data.
On Sat, 19 May 2001, Matthew Wilcox wrote:
> On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote:
> > clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add
> > unopened descriptors. I.e. no IO until you open it (turning the thing into
> > opened one), but we can do
On Sat, 19 May 2001, Alexander Viro wrote:
>
> Folks, before you get all excited about cramming side effects into
> open(2), consider the following case:
Your argument is stupid, imnsho.
Side-effects are perfectly fine if they are _local_ to the file
descriptor. Your example is
On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote:
> clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add
> unopened descriptors. I.e. no IO until you open it (turning the thing into
> opened one), but we can do lookups (move to child), we can clone and
> kill them
>> Opening device files often has interesting side effects.
> Too bad. They can be triggered by similar races between attacker
> changing the type of object (file<->symlink) and backup.
Yes. This is a well-known security problem.
Doing
stat("file", );
if (action desired) {
On Sat, 19 May 2001, Abramo Bagnara wrote:
> Can't this easily avoided if the needed action is not
>
> < /dev/zero/start_nuclear_war
> or
> > /dev/zero/start_nuclear_war
>
> but
>
> echo "I'm evil" > /dev/zero/start_nuclear_war
Sure. And that's the right thing to do (not the implied
Alexander Viro wrote:
>
> Folks, before you get all excited about cramming side effects into
> open(2), consider the following case:
>
> 1) opening "/dev/zero/start_nuclear_war" has a certain side effect.
>
> 2) Local user does the following:
> ln -sf
On Sat, 19 May 2001 [EMAIL PROTECTED] wrote:
> > A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
> > is a no-op. Breaking that assumption is a Bad Thing(tm).
>
> Also here I would like to agree. Unfortunately this is false.
> Opening device files often has interesting side
Alexander Viro writes:
> Folks, before you get all excited about cramming side effects
> into open(2), consider ...
I agree completely.
> A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
> is a no-op. Breaking that assumption is a Bad Thing(tm).
Also here I would like to
Folks, before you get all excited about cramming side effects into
open(2), consider the following case:
1) opening "/dev/zero/start_nuclear_war" has a certain side effect.
2) Local user does the following:
ln -sf /dev/zero/start_nuclear_war bar
while true; do
Here's a dumb question, and I apologize if I am questioning computer
science dogma...
Why are LVM and EVMS(competing LVM project) needed at all?
Surely the same can be accomplished with
* md
* snapshot blkdev (attached in previous e-mail)
* giving partitions and blkdevs the ability to grow and
On Sun, 20 May 2001, Edgar Toernig wrote:
That assumption is totally bogus. Even for regular files you have side
effects (atime); for anything else they're unpredictable.
That means only one thing: safe backups are possible only in single-user
mode. For values of safe being not triggering
Alexander Viro writes:
Folks, before you get all excited about cramming side effects
into open(2), consider ...
I agree completely.
A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
is a no-op. Breaking that assumption is a Bad Thing(tm).
Also here I would like to agree.
On Sat, 19 May 2001 [EMAIL PROTECTED] wrote:
A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
is a no-op. Breaking that assumption is a Bad Thing(tm).
Also here I would like to agree. Unfortunately this is false.
Opening device files often has interesting side effects.
Linus Torvalds wrote:
There are some strong arguments that we should have filesystem
backdoors for maintenance purposes, including backup.
I think I agree with something Al said over IRC, that fs-level snapshots
are preferred over block level snapshots.
fs-level snapshots should become easy
Alexander Viro wrote:
Folks, before you get all excited about cramming side effects into
open(2), consider the following case:
1) opening /dev/zero/start_nuclear_war has a certain side effect.
2) Local user does the following:
ln -sf /dev/zero/start_nuclear_war bar
Jeff Garzik wrote:
Notice also a metadata miscdev solves the problem of passing options
on open -- just pass those options to the miscdev before you open it...
to be more clear, it == the data device, not the metadata miscdev
--
Jeff Garzik | Do you have to make light of everything?!
On Sat, 19 May 2001, Matthew Wilcox wrote:
On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote:
clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add
unopened descriptors. I.e. no IO until you open it (turning the thing into
opened one), but we can do lookups
On Sat, 19 May 2001, Alexander Viro wrote:
On Sun, 20 May 2001, Edgar Toernig wrote:
That assumption is totally bogus. Even for regular files you have side
effects (atime); for anything else they're unpredictable.
That means only one thing: safe backups are possible only in
Opening device files often has interesting side effects.
Too bad. They can be triggered by similar races between attacker
changing the type of object (file-symlink) and backup.
Yes. This is a well-known security problem.
Doing
stat(file, s);
if (action desired) {
On Sat, 19 May 2001, Alexander Viro wrote:
Folks, before you get all excited about cramming side effects into
open(2), consider the following case:
Your argument is stupid, imnsho.
Side-effects are perfectly fine if they are _local_ to the file
descriptor. Your example is contrieved
Are we talking about device arguments just for chrdevs and blkdevs?
(ie. drivers) or for regular files too?
Speaking about drivers specifically, a controlling miscdev, one per
device or one per group of devices depending on your needs, is a much
more clean solution for passing ioctl-type data.
nitpicking: a system call without side effects would be pretty useless.
Alexander Viro wrote:
A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a
no-op. Breaking that assumption is a Bad Thing(tm).
That assumption is totally bogus. Even for regular files you have side
Folks, before you get all excited about cramming side effects into
open(2), consider the following case:
1) opening /dev/zero/start_nuclear_war has a certain side effect.
2) Local user does the following:
ln -sf /dev/zero/start_nuclear_war bar
while true; do
On Sat, 19 May 2001, Abramo Bagnara wrote:
Can't this easily avoided if the needed action is not
/dev/zero/start_nuclear_war
or
/dev/zero/start_nuclear_war
but
echo I'm evil /dev/zero/start_nuclear_war
Sure. And that's the right thing to do (not the implied action, that is -
On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote:
clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add
unopened descriptors. I.e. no IO until you open it (turning the thing into
opened one), but we can do lookups (move to child), we can clone and
kill them and
On Sat, 19 May 2001, Jeff Garzik wrote:
Are we talking about device arguments just for chrdevs and blkdevs?
(ie. drivers) or for regular files too?
Let's distinguish between per-fd effects (that's what name in open(name, flags)
is for - you are asking for descriptor and telling what
95 matches
Mail list logo
