On Sat, Oct 12, 2002 at 09:26:52PM +0200, Philipp Mergenthaler wrote:
> > Where is stuff like this documented for end-users?
>
> AFAIK right now it is only documented in sys/conf/NOTES. I've sent
> PR docs/39748 some time back which has a patch similar to yours
> (I forgot about the module, though
< said:
> I am trying to port the ACE library (
> http://www.cs.wustl.edu/~schmidt/ACE.html ) to FreeBSD-CURRENT, and
> it is very confusing that code in -STABLE which compiled and worked,
> does not work the same way in -CURRENT. (ie. the code compiles, but
> it crashes because of a new kernel
On Sat, Oct 12, 2002 at 11:57:23AM -0400, Craig Rodrigues wrote:
> > > > I just did a cvsup and rebuilt the world on my -CURRENT system.
> > > > If I try to run the following program, I get a "Bad system call" coredump:
> > > [...]
> > > >
tem.
> > > If I try to run the following program, I get a "Bad system call" coredump:
> > [...]
> > > 2660 a.out CALL aio_read(0xbfbffb88)
> > > 2660 a.outRET aio_read -1 errno 78 Function not implemented
> >
> > Does your kernel
t; coredump:
> [...]
> > 2660 a.outCALL aio_read(0xbfbffb88)
> > 2660 a.outRET aio_read -1 errno 78 Function not implemented
>
> Does your kernel configuration file contain the line "options VFS_AIO"?
> I have a kernel (with this option)+world from ye
On Sat, Oct 12, 2002 at 09:53:02AM -0400, Craig Rodrigues wrote:
> I just did a cvsup and rebuilt the world on my -CURRENT system.
> If I try to run the following program, I get a "Bad system call" coredump:
[...]
> 2660 a.outCALL aio_read(0xbfbffb88)
> 2660 a.ou
Hi,
I just did a cvsup and rebuilt the world on my -CURRENT system.
If I try to run the following program, I get a "Bad system call" coredump:
#include
#include
int main(int argc, char *argv[]) {
struct aiocb b;
aio_read(&b);
}
./a.out
Bad system call (core dumped)
If I
> If it's a redirected output file you simply make it O_APPEND, at which
> point the seek offset in the descriptor becomes irrelevant.
As others have pointed out, O_APPEND is much newer than the
offset-sharing behavior.
It also doesn't fix things for inputs. Of course with buffering, it
At 5:00 pm -0700 6/4/99, John Polstra wrote:
>[...]
>But O_APPEND didn't exist in early versions of Unix. I'm sure it
>wasn't present in V6, and I'm pretty sure it wasn't present in V7
>either.
[Blows dust off V7 manual]
You're right: it wasn't.
--
Bob Bishop (0118) 977 4017 inte
In article <199904061701.kaa09...@apollo.backplane.com>,
Matthew Dillon wrote:
> :
> :It's not necessarily breakage. Not having any mechanism other than
> :open to get your own seek offset is nasty, but sharing a seek offset
> :can also be useful. File descriptors can't be "reverse-inherited",
:
:
:Matthew Dillon writes:
:
:> UNIX has been broken this way from day 1. It was a major design mistake.
:> The only way to get your own descriptor seek offset is to open() the
:> file again.
:
:It's not necessarily breakage. Not having any mechanism other than
:open to get your ow
Matthew Dillon writes:
> UNIX has been broken this way from day 1. It was a major design mistake.
> The only way to get your own descriptor seek offset is to open() the
> file again.
It's not necessarily breakage. Not having any mechanism other than
open to get your own seek offse
:> design mistake.
:> The only way to get your own descriptor seek offset is to
:> open() the file again.
:
:After you said this, I found it so hard to believe that I had
:to go look.
:
:All I can say is, well I'll be damned; you could knock me over
:with a feather, and that doesn't ha
On Mon, 5 Apr 1999, Terry Lambert wrote:
> After you said this, I found it so hard to believe that I had
> to go look.
:-)
> All I can say is, well I'll be damned; you could knock me over
> with a feather, and that doesn't happen often.
>
> I'm sure SVR4 and UnixWare is not like this; I had to
Matthew Dillon wrote:
> :This was not my impression; I thought that children had
> :their own descriptor entries on a per-process basis, but
> :that they all pointed to the same open file entry when
> :inherited. I was contemplating adding a
>
> They do indeed point to the same file entry. A
:
:This was not my impression; I thought that children had their own
:descriptor entries on a per-process basis, but that they all pointed to
:the same open file entry when inherited. I was contemplating adding a
They do indeed point to the same file entry. Also, when you dup() a
descrip
On Mon, 5 Apr 1999, Terry Lambert wrote:
> > What I would like to do is have a child process read
> > from an inherited file descriptor without affecting the
> > parent process's access to the descriptor (for example,
> > the offset it reads from using a normal read() or readv()).
>
> This should
Robert Watson wrote:
>
> Terry,
>
> In the BUGS section of the 4.0-CURRENT aio_read man page,
> the following comment is made:
>
> The value of iocb->aio_offset is ignored.
>
> Is this actually the case, and what would be required to
> fix it? Does thi
:Terry,
:
:In the BUGS section of the 4.0-CURRENT aio_read man page, the following
:comment is made:
:
: The value of iocb->aio_offset is ignored.
:
:Is this actually the case, and what would be required to fix it? Does
:this comment imply that reads always occur at the current file off
Terry,
In the BUGS section of the 4.0-CURRENT aio_read man page, the following
comment is made:
The value of iocb->aio_offset is ignored.
Is this actually the case, and what would be required to fix it? Does
this comment imply that reads always occur at the current file offset f
Brian Dean said:
>
> I'm using a dual 350MHz Dell Precision 410 with 4.0-19990130-SNAP (SMP
> enabled) to prototype a program that uses asynchronous read and write
> (aio_read() and aio_write()), and found that the following simple and
> not very useful program (it's f
Hi,
I'm using a dual 350MHz Dell Precision 410 with 4.0-19990130-SNAP (SMP
enabled) to prototype a program that uses asynchronous read and write
(aio_read() and aio_write()), and found that the following simple and
not very useful program (it's for demonstration purposes only!) causes
22 matches
Mail list logo
