bugThe GNU Hurd - Bugs: bug #15319, term doesn't recognize open...

 
 

bug #15319: term doesn't recognize open failures

Submitter:  Samuel Thibault <sthibaul>
Submitted:  Thu 29 Dec 2005 09:07:32 PM UTC
   
 
Category:  Hurd Servers Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Reproducibility:  Every Time
Size (loc):  None Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 30 Dec 2005 08:22:22 PM UTC, comment #2: 

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.

Samuel Thibault <sthibaul>
Group administrator
Fri 30 Dec 2005 06:08:07 PM UTC, comment #1: 

Is this still happening?

I'm not in GNU/Hurd to try this, so I'm marking it as `Fixed' since  there is already a fix commited to the CVS.

Alfred M. Szmidt <ams>
Thu 29 Dec 2005 09:07:32 PM UTC, original submission:  

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


Samuel Thibault <sthibaul>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #2283:  patch added by sthibaul (5KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-12-31 ams StatusFixed Confirmed
2005-12-30 ams StatusNone Fixed
2005-12-29 sthibaul Attached File- Added patch, #3224

Back to the top

Powered by Savane 3.13-3230.
Corresponding source code