public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: vt.c: unimap changes to (fg_?)console
Date: 7 May 2001 06:45:52 -0700	[thread overview]
Message-ID: <9d68ug$g7n$1@cesium.transmeta.com> (raw)
In-Reply-To: <20010507123709.D8052@garloff.suse.de>

Followup to:  <20010507123709.D8052@garloff.suse.de>
By author:    Kurt Garloff <garloff@suse.de>
In newsgroup: linux.dev.kernel
> 
> Hi Linus, Alan, Andries,
> 
> if you open /dev/tty4 and change the font via ioctl(KDFONTOP), it will be
> applied to the opened console, i.e. tty4. Then you set the corresponding
> unicodemap via PIO_UNIMAPCLR and PIO_UNIMAP ioctls. Those get applied to the
> current foreground console. Which is inconsistent.
> 
> Looking at vt.c: vt_ioctl(), the situation is a bit messy: Some ioctls don't
> explicitly specify a tty (probably not needed, as some settings are global),
> some apply to fg_console, some apply to the opened console which is
> ((struct vt_struct*)tty->driver_data)->vc_num.
> 

Okay, these should either be global or apply to the invoked (file
descriptor) tty.  Anything else is completely broken.  In fact, I'd
argue that using ioctl's for anything but global data (since it's
global, it has to be privileged) is in itself broken.  (Note: all the
font stuff used to be global state for kernel memory reasons.)

Why do you have the following in your patch?  It makes the permissions
on the console depend on whether or not it is in the foreground, which
seems like another stupid inconsistency:

> +		if (!perm && fg_console !=3D console)
> +			return -EPERM;
	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

      reply	other threads:[~2001-05-07 13:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-07 10:37 vt.c: unimap changes to (fg_?)console Kurt Garloff
2001-05-07 13:45 ` H. Peter Anvin [this message]

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='9d68ug$g7n$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /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