It is still happening on my hurd box.  Just set a com3 translator for a non-existent com3 gnumach device, and try to cat it: no error.

From http://bugs.debian.org/45796

From: -email is unavailable-
To: -email is unavailable-
Subject: hurd: term doesn't recognize open failures
Date: Wed, 22 Sep 1999 22:31:34 +0200

Package: hurd
Version: N/A
Severity: normal

Hello,

term doesn't barf at you if a device doesn't exist.
The script below shows that storio does.

Script started on Wed Sep 22 22:02:55 1999
hurd:/dev# devprobe com0 hd2s5 hd1s2
hd2s5
hurd:/dev# showtrans com0 hd2s5 hd1s2
com0: /hurd/term /dev/com0 device com0
hd2s5: /hurd/storeio hd2s5
hd1s2: /hurd/storeio hd1s2
hurd:/dev# cat com0
^C
hurd:/dev# cat hd1s2
cat: hd1s2: Device not configured
hurd:/dev# cat hd2s5
<lots of garbage here of course>

The problem is that with device_open_request, it seems to be hard
(impossible?) to return an error to the user. This is suboptimal. The same
problem exists in the streamdev translator, btw. I can transfer any fix from
term to streamdev (or at least hope to be able to do so).

BTW, what is the advantage of device_open_reply as opposed to device_open?
Is it a reqirement for the other _reply functions? I can't see a reason why
opening a device should block or something like this...

Thanks,
Marcus


From: -email is unavailable- (Thomas Bushnell, BSG)
To: -email is unavailable-
Cc: 45796@bugs.debian.org, -email is unavailable-
Subject: Re: Bug #45796: hurd: term doesn't recognize open failures
Date: 24 Sep 1999 02:18:02 -0400

-email is unavailable- writes:

> BTW, what is the advantage of device_open_reply as opposed to device_open?
> Is it a reqirement for the other _reply functions? I can't see a reason why
> opening a device should block or something like this...

Unfortunately, the device open blocks until carrier is established
(which is the Unix semantics of open).  So a fix to use device_open
will result in a block at the wrong time.  (Note that devio.c is
careful to interpret the reply as "carrier has turned on" at the end
of the function:

  report_carrier_on ();
  if (err)
    devio_desert_dtr ();

  open_pending = NOTPENDING;

The Mach device interface has many problems, especially for terminals,
where the wrong level of control is being provided.

However, streamdev needs none of this complexity.  I haven't had a
chance to look at your code yet, but I suspect the entire level of
indirection between users.c and the "bottom halves" is not necessary,
and there is certainly no need to worry about the weird carrier
semantics of terminals.  Just go ahead and have the open_hook do a
simple device_open and report the error appropriately.

The problem here with term is a real bug tho, so I'll work on it.  But
it shouldn't delay you from making streamdev do the right thing.

(Note that I was aware of this problem when I wrote term; the relevant
code in devio.c says "Bogus" and then tries to recover somehow.)  I'll
probably make a fix by adding a flag and a global variable to
communicate the error back, but this should not be copied into
streamdev, which doesn't need to be so complex anyhow.

Thomas


From: Roland McGrath <roland@gnu.org>
To: Marcus.Brinkmann@ruhr-uni-bochum.de, -email is unavailable-
Subject: Re: Bug #45796: hurd: term doesn't recognize open failures
Date: Fri, 1 Oct 1999 17:46:18 -0400

I've checked in the following changes, which seem to work for me.
That is, bogus devices return an error and /dev/console still works.
If things are good for you with this, please close the bug.
Thomas might well still want to rewrite this, but this seems to do for now.


See patch