Re: My ATAPI CD not come ready

2000-01-24 Thread Soren Schmidt
It seems Motomichi Matsuzaki wrote: > > Thank you for fixing, but still not probed. > What can I do for your work? > ata-pci0: port 0xf000-0xf00f at device 7.1 on pci0 > ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xf000 > ata0: mask=03 status0=50 status1=00 > ata0: mask=03 status0=00 status1=00

Re: ascii art in hosts.allow

2000-01-24 Thread David O'Brien
On Tue, Jan 25, 2000 at 03:03:32PM +1100, Andy Farkas wrote: > What is the reason for putting a giant "Example!" in hosts.allow? So you'll notice that this file is an example and *demands* your attention in configuring your system properly. > I note that it was committed at 3 o'clock in the mor

Re: ascii art in hosts.allow

2000-01-24 Thread David O'Brien
On Tue, Jan 25, 2000 at 03:03:32PM +1100, Andy Farkas wrote: > Here is a patch: (please notice the spelling correction) Where? I just ran ispell on src/etc/hosts.allow and it didn't catch anything. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsu

Re: My ATAPI CD not come ready

2000-01-24 Thread Motomichi Matsuzaki
At Tue, 25 Jan 2000 08:29:32 +0100 (CET), Soren Schmidt <[EMAIL PROTECTED]> wrote: > > Thank you for fixing, but still not probed. > > ata-pci0: port 0xf000-0xf00f at device 7.1 on pci0 > > ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xf000 > > ata0: mask=03 status0=50 status1=00 > > ata0: mask=

Re: ascii art in hosts.allow

2000-01-24 Thread Kevin Day
> > On Tue, Jan 25, 2000 at 03:03:32PM +1100, Andy Farkas wrote: > > Here is a patch: (please notice the spelling correction) > > Where? I just ran ispell on src/etc/hosts.allow and it didn't catch > anything. A more direct patch would have been: -# NOTE: The hosts.deny file is not longer us

Re: [ID 20000124.004] "perl in malloc(): warning: recursive call" on

2000-01-24 Thread Ilya Zakharevich
Lars Eggert writes: > Running the following test script causes perl to crash. You may need > to run the script several times before seeing the problem. (The script > spawns a child process that does nothing but write to an array. The > parent signals the child periodically.) Signals and Perl do n

Re: [ID 20000124.004] "perl in malloc(): warning: recursive call"on

2000-01-24 Thread Lars Eggert
Ilya, thanks for the quick response. > Signals and Perl do not mix. Please do not use signals if a segfault > is not a desirable form of output. Never? After reading perlipc I was under the impression that using signals was okay if you keep your handlers simple. I may have to use to another fo

Re: [ID 20000124.004] "perl in malloc(): warning: recursive call" on

2000-01-24 Thread Ilya Zakharevich
On Mon, Jan 24, 2000 at 09:53:27PM -0800, Lars Eggert wrote: > > Signals and Perl do not mix. Please do not use signals if a segfault > > is not a desirable form of output. > > Never? Never. Well, I did not try XSUB signal handlers, but if it is a Perl subroutine, then the harm may be already

BPF bug or not?

2000-01-24 Thread Yevmenkin, Maksim N, CSCIO
All, I've just found that read from /dev/bpfX never return EAGAIN/EWOULDBLOCK. It means that when you do a non blocking read and there is no data you will always get 0. Does it suppose work this way? A non blocking read from pipe return EAGAIN/EWOULDBLOCK if there is no data and pipe was opened

Re: indirection in bus space

2000-01-24 Thread Luoqi Chen
> Do you have any comment anout the patch? If there isn't any big > problem, I hope to commit it to current. > > Thank you. > > > I wrote: > > Do you remember this topic? I have revised the indirection support > > patch. What I have changed are: > > - to make diff files more readable > >

Re: indirection in bus space

2000-01-24 Thread KATO Takenori
Luoqi Chen <[EMAIL PROTECTED]> wrote: > We shouldn't need bus_simple_create_bsh(). All drivers ought to use > rman_get_bushandle()/rman_get_bustag() to retrieve the bus handle and tag, > and use them in bus_space_read/write calls to perform device io. Drivers > that don't do that should be fixed.

Re: indirection in bus space

2000-01-24 Thread Luoqi Chen
> > Why have two files bus_at386.h and bus_pc98.h? I386_BUS_PIO_IND should be > > able to live with I386_BUS_PIO and I386_BUS_MEMIO happily together. > > Because they are different in the type of bus_space_tag_t from each > other. It is the u_long in PC/AT and the structure in PC-98. For > exam

Re: indirection in bus space

2000-01-24 Thread KATO Takenori
Luoqi Chen <[EMAIL PROTECTED]> wrote: > You could set the handle to point to the structure instead: I think it is difficult to implement such conversion because: - Not only bus space stuff also resource manager stuff need to perform such conversion. - The type of the bus_space_handle_t

Re: indirection in bus space

2000-01-24 Thread Luoqi Chen
> I think it is difficult to implement such conversion because: > > - Not only bus space stuff also resource manager stuff need to > perform such conversion. Why? Both bus_space_handle_t and bus_space_tag_t are supposed to be opaque types. Resource manager needs not know the implementation

<    1   2