Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jun 2004 20:21:49 +0200
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        current@freebsd.org
Subject:   Re: [REVIEW] move tty lock/initial up in the stack 
Message-ID:  <70381.1087669309@critter.freebsd.dk>
In-Reply-To: Your message of "Sat, 19 Jun 2004 20:59:11 %2B1000." <20040619193901.W770@gamplex.bde.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20040619193901.W770@gamplex.bde.org>, Bruce Evans writes:
>On Sat, 19 Jun 2004, Poul-Henning Kamp wrote:
>
>> This patch moves the "lock/initial" facility known from sio(4) up
>> to the generic tty layer.
>
>Just moving them is OK.  Unfortunately, the patch does less than move
>them ...
>
>... starting here.  Control devices in general must be separate so that
>they can have different ownership and permissions, and can be opened
>without side effects.  For sio devices, the non-control devices can't
>even be opened if the complementary non-control device is open.

I'm not keen on adding four control devices for all ttys in the system,
and therefore I decided to collapse the states for both directions and
use inband signalling for the changes.  I could be persuaded to have
a single control-device per tty.

>This is missing moving the lock state handling, which comprises about half
>of the code that can be moved.

This is only the first step of the journey.

>The new cases don't belong in this case statement anyway, since the new
>ioctls don't involve modification of the active part of the tty struct.

I'm not sure I agree, but I don't care much either way.

I want to get rid of this duplication of the switch anyway, and use
a function call to do the background check and add that functioncall
where each ioctl is implemented.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70381.1087669309>