From: Jesse Pollard <jesse@cats-chateau.net>
To: Tim Jansen <tim@tjansen.de>, James Simmons <jsimmons@transvirtual.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: The new X-Kernel !
Date: Sun, 21 Oct 2001 19:10:32 -0500 [thread overview]
Message-ID: <01102119103200.19723@tabby> (raw)
In-Reply-To: <Pine.LNX.4.10.10110211025130.13079-100000@transvirtual.com> <15vO3W-0DSqTwC@fmrl00.sul.t-online.com>
In-Reply-To: <15vO3W-0DSqTwC@fmrl00.sul.t-online.com>
On Sunday 21 October 2001 14:17, Tim Jansen wrote:
> On Sunday 21 October 2001 19:40, James Simmons wrote:
> > It sets the hardware state of the keyboards and the
> > mice. The user runs apps that alter the state. The second user comes
> > along and log in on desktop two. He runs another small application to
> > test the mice. It changes the state which in turn effects the person on
> > desktop one.
>
> Isn't this a driver problem? If two processes can interfere when using the
> same device the driver should only allow one access (one device file
> opened) at a time. And if two processes need to access it it should be
> managed by a daemon.
Neither - It is a resource allocation problem, which all UNIX style systems
seem to lack. And second, it doesn't happen at the present time with
mice/keyboard/display unless somebody (root) did not configure the system
properly (as in leave the device inodes accessable to world) OR change the
protection to permit access.
Once a resource is allocated to a user session (not process) it should not be
accessable to other users.
Linux doesn't have a resource allocation other than the limited single open
support for character device drivers. This is usually sufficient for
keyboard/mouse/display since it is the X server that is opening the device.
It is NOT sufficient for things like tape drives. The only way to prevent
conflict at the present time is to change the ownership of the inode, and
ensure that the protection mask only permits user access. It is ALSO
necessary to ensure that no other processes have that device open at the same
time.
How those devices are controled/configured/used after allocation is and
should remain a user mode function, NOT a kernel function.
next prev parent reply other threads:[~2001-10-22 0:10 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-20 21:30 The new X-Kernel ! MichaelM
2001-10-20 21:43 ` Mike Fedyk
2001-10-21 0:08 ` Aaron Lehmann
2001-10-21 7:37 ` Gábor Lénárt
2001-10-21 8:33 ` Jonathan Morton
2001-10-21 8:50 ` Gábor Lénárt
2001-10-21 9:13 ` Jonathan Morton
2001-10-21 17:06 ` James Simmons
2001-10-21 10:26 ` Allan Sandfeld
2001-10-21 14:19 ` Alan Cox
2001-10-21 17:18 ` James Simmons
2001-10-21 17:26 ` Alan Cox
2001-10-21 17:40 ` James Simmons
2001-10-21 19:17 ` Tim Jansen
2001-10-22 0:10 ` Jesse Pollard [this message]
2001-10-22 0:37 ` Tim Jansen
2001-10-22 17:18 ` James Simmons
2001-10-22 16:51 ` James Simmons
2001-10-22 18:35 ` Tim Jansen
2001-10-23 7:05 ` Allan Sandfeld
2001-10-21 19:53 ` Gábor Lénárt
2001-10-22 17:04 ` James Simmons
2001-10-23 6:45 ` Albert D. Cahalan
2001-10-21 12:54 ` Tim Jansen
2001-10-21 15:37 ` john slee
2001-10-21 19:04 ` Tim Jansen
2001-10-21 20:03 ` Gábor Lénárt
2001-10-21 21:06 ` LPP (was: The new X-Kernel !) Tim Jansen
2001-10-21 21:22 ` The new X-Kernel ! Federico Sevilla III
2001-10-21 21:31 ` Gábor Lénárt
2001-10-21 21:38 ` Sean Cavanaugh
2001-10-21 21:52 ` Alan Cox
2001-10-21 22:39 ` Oden Eriksson
2001-10-22 4:44 ` Sean Cavanaugh
2001-10-21 21:53 ` Gábor Lénárt
2001-10-21 22:19 ` LPP (was: The new X-Kernel !) Tim Jansen
2001-10-22 0:28 ` Jakob Østergaard
2001-10-22 0:57 ` Tim Jansen
2001-10-22 8:34 ` Abraham vd Merwe
2001-10-22 0:24 ` Ragnar Hojland Espinosa
2001-10-23 20:50 ` Petr Baudis
2001-10-30 2:18 ` Ragnar Hojland Espinosa
2001-10-22 9:37 ` Sunil Phatak
2001-10-22 9:47 ` Abraham vd Merwe
2001-10-22 14:33 ` MichaelM
2001-10-22 19:13 ` Mike Fedyk
2001-10-22 11:42 ` David Relson
2001-10-21 22:14 ` The new X-Kernel ! Leo Spalteholz
2001-10-22 5:17 ` Jonathan Morton
2001-10-21 16:09 ` Malcolm H. Teas
2001-10-21 19:04 ` Tim Jansen
2001-10-21 19:13 ` Bernd Eckenfels
2001-10-21 19:30 ` Gábor Lénárt
2001-10-21 19:49 ` J Sloan
2001-10-21 21:12 ` Tim Jansen
2001-10-21 21:20 ` D. Stimits
2001-10-21 21:41 ` Gábor Lénárt
2001-10-22 5:42 ` Dwayne C. Litzenberger
2001-10-31 17:34 ` Jim Freeman
-- strict thread matches above, loose matches on Subject: below --
2001-10-21 21:44 Samium Gromoff
2001-10-21 22:01 ` Gábor Lénárt
[not found] <fa.fbu5gjv.1526gp4@ifi.uio.no>
[not found] ` <fa.ltbaijv.13jgcr7@ifi.uio.no>
2001-10-22 1:14 ` Dan Maas
2001-10-22 8:09 ` Alan Cox
2001-10-22 17:56 Jesse Pollard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01102119103200.19723@tabby \
--to=jesse@cats-chateau.net \
--cc=jsimmons@transvirtual.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tim@tjansen.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox