faucet

Dear Sir or Madam, We write to introduce ourselves as one of the manufactories in China, of a wide range of bathroom hardware. We can supply different type of bathroom Hardwares at present,and hope these items will interest you, it will be a great pleasure to receive you any inquiries against whi

Re: ioperm and pseudo devices

> Yeah, I was thinking of that. In fact, the reason I became aware of that is > that I wanted to use another pseudo device with no ops for the proxy memory > objects (but for those I need a close function, so I made my own device ops > structure). I know that this is lame, as one reason against a

Re: /dev/console switching : fix: term doesn't copy arg for outputdevice.

Thanks, I've put in a similar fix. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

/dev/console switching : fix: term doesn't copy arg for outputdevice.

fix: term doesn't copy arg for output device. the following works for me given the changes below fsysopts /dev/console /dev/vcs/10/console -- Where I have been dumping syslog output. -- Now console messages show up 'rightly' :) Question: I don't see a join in the (*bottom->finis)() calls.

Re: ioperm and pseudo devices

On Tue, Nov 19, 2002 at 07:17:12PM -0500, Roland McGrath wrote: > > I think we need a flag in the device structure to mark the type of the > > device more properly than the device ops does. In particular, I am worried > > about someone sending an io perm modify IPC to a non-io perm device port, it

Re: ioperm and pseudo devices

> I think we need a flag in the device structure to mark the type of the > device more properly than the device ops does. In particular, I am worried > about someone sending an io perm modify IPC to a non-io perm device port, it > doesn't look to me as if I coded any guard against this into it. T

ioperm and pseudo devices

Hi, I think we need a flag in the device structure to mark the type of the device more properly than the device ops does. In particular, I am worried about someone sending an io perm modify IPC to a non-io perm device port, it doesn't look to me as if I coded any guard against this into it. Than

Re: Hurd_condition_wait

Marcus Brinkmann <[EMAIL PROTECTED]> writes: > On Sun, Nov 17, 2002 at 12:24:03PM -0500, Neal H. Walfield wrote: > > > Is there a race condition before __pthread_block? We can receive > > > pthread_broadcast before we have blocked. > > > If so, how do we solve that? > > > > As I said in a previo

Re: POSIX semaphore for GNU/Hurd

Sending what I have so far. Hopefully I'll be able to read any comments next wek. On Thu, Nov 07, 2002 at 10:22:09AM -0500, Neal H. Walfield wrote: > > > not conform to the GNU coding standards; this will have to be fixed. It probably still does not, I'll have to read the GCS carefully when I have