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

 
 

bug #15319: term doesn't recognize open failures

Submitted by:  Samuel Thibault <sthibaul>
Submitted on:  Thu 29 Dec 2005 09:07:32 PM UTC  
 
Category: Hurd ServersSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: ConfirmedPrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: OpenReproducibility: Every Time
Size (loc): NonePlanned Release: None
Effort: 0.00
Wiki-like text discussion box: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project Member
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: -unavailable-
To: -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: -unavailable- (Thomas Bushnell, BSG)
To: -unavailable-
Cc: 45796@bugs.debian.org, -unavailable-
Subject: Re: Bug #45796: hurd: term doesn't recognize open failures
Date: 24 Sep 1999 02:18:02 -0400

-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, -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>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 3 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sat 31 Dec 2005 10:37:28 AM UTCamsStatusFixed=>Confirmed
Fri 30 Dec 2005 06:08:07 PM UTCamsStatusNone=>Fixed
Thu 29 Dec 2005 09:07:32 PM UTCsthibaulAttached File-=>Added patch, #3224

Back to the top


Powered by Savane 3.1-cleanup