From: Andrew Morton <akpm@linux-foundation.org>
To: Cedric Roux <sed@free.fr>
Cc: linux-kernel@vger.kernel.org, mtk.manpages@gmail.com,
linux-api@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 1/1] vt: add ioctl commands to /dev/vcsaX to get/put the current palette of the given tty
Date: Mon, 2 Mar 2009 13:27:41 -0800 [thread overview]
Message-ID: <20090302132741.26eaf124.akpm@linux-foundation.org> (raw)
In-Reply-To: <17015927.368551235932826484.JavaMail.root@spooler2-g27.priv.proxad.net>
On Sun, 1 Mar 2009 19:40:26 +0100 (CET)
Cedric Roux <sed@free.fr> wrote:
> From: Cedric Roux <sed@free.fr>
>
> Adding a ioctl interface and two ioctl commands to /dev/vcsaX
> to get/put the current palette of the given tty.
>
Please also cc linux-api on API-affecting changes.
> ---
> This patch exists because there is no way to get the current
> installed palette of a given tty. The PIO_CMAP and GIO_CMAP
> in vt_ioctl.c:vt_ioctl play with the global default colormap.
> And /dev/vcsaX don't dump the palette through their read
> interface. And since a user may change colors of a given
> tty by escape sequences, one should be able to retrieve
> the palette through /dev/vcsaX, leading to this patch.
>
> Some points I am not fully confident with:
> - I am not sure about the return values in case of error.
Me either.
> - vt.c:set_colormap is now used in vc_screen.c so cannot be static
> anymore.
> The goal of this patch is to allow read access to the palette,
> I can remove the PIO_CMAP case and make set_colormap static again.
> This case is there because /dev/vcsaX is read/write so the access
> to the palette should also be read/write. (Or I can do it
> differently, no problem, just tell me how.)
>
> (In case of formatting problem of this mail, I apologize.
> I have a very bad mail access... Just tell me and I'll
> do my best to resend something clean.)
>
> diff -uprN -X linux-2.6.28/Documentation/dontdiff linux-2.6.28-vanilla/drivers/char/vc_screen.c linux-2.6.28/drivers/char/vc_screen.c
> --- linux-2.6.28-vanilla/drivers/char/vc_screen.c 2008-12-24 23:26:37.000000000 +0000
> +++ linux-2.6.28/drivers/char/vc_screen.c 2009-03-01 17:42:59.000000000 +0000
> @@ -19,6 +19,8 @@
> * machek@k332.feld.cvut.cz - modified not to send characters to wrong console
> * - fixed some fatal off-by-one bugs (0-- no longer == -1 -> looping and looping and looping...)
> * - making it shorter - scr_readw are macros which expand in PRETTY long code
> + *
> + * Colormap put/get for /dev/vcsaX, Cedric Roux <sed@free.fr>, March 2009.
> */
>
> #include <linux/kernel.h>
> @@ -470,11 +472,64 @@ vcs_open(struct inode *inode, struct fil
> return ret;
> }
>
> +static int
> +vcs_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + unsigned int currcons = iminor(inode);
> + struct vc_data *vc;
> + unsigned char pal[16*3];
> + int ret = 0;
> +
> + /* access only defined for /dev/vcsaX, not /dev/vcsX */
> + if (currcons < 128)
> + return -ENOIOCTLCMD;
What's going on with vfs_ioctl():
if (filp->f_op->unlocked_ioctl) {
error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
if (error == -ENOIOCTLCMD)
error = -EINVAL;
goto out;
} else if (filp->f_op->ioctl) {
lock_kernel();
error = filp->f_op->ioctl(filp->f_path.dentry->d_inode,
filp, cmd, arg);
unlock_kernel();
}
So if ->unlocked_ioctl exists we'll convert ENOIOCTLCMD into EINVAL.
Isn't that supposed to be ENOTTY? The comment thinks so:
* Invokes filesystem specific ->unlocked_ioctl, if one exists; otherwise
* invokes filesystem specific ->ioctl method. If neither method exists,
* returns -ENOTTY.
If ->unlocked_ioctl doesn't exist, we'll return ENOIOCTLCMD back to
userspace, I think. That would be wrong.
> + acquire_console_sem();
> +
> + currcons &= 127;
> + if (currcons == 0)
> + currcons = fg_console;
> + else
> + currcons--;
> + if (!vc_cons_allocated(currcons)) {
> + ret = -ENXIO;
> + goto unlock_out;
> + }
> + vc = vc_cons[currcons].d;
> +
> + switch (cmd) {
> + case PIO_CMAP:
> + if (copy_from_user(pal, (void __user *)arg, 16*3)) {
> + ret = -EFAULT;
> + goto unlock_out;
> + }
> + memcpy(vc->vc_palette, pal, 16*3);
> + set_palette(vc);
> + break;
> + case GIO_CMAP:
> + if (copy_to_user((void __user *)arg, vc->vc_palette, 16*3)) {
> + ret = -EFAULT;
> + goto unlock_out;
> + }
> + break;
> + default:
> + ret = -ENOIOCTLCMD;
> + break;
> + }
> +
> +unlock_out:
> + release_console_sem();
> +
> + return ret;
> +}
> +
> static const struct file_operations vcs_fops = {
> .llseek = vcs_lseek,
> .read = vcs_read,
> .write = vcs_write,
> .open = vcs_open,
> + .ioctl = vcs_ioctl,
> };
.ioctl is old and deprecated. Please use .unlocked_ioctl
prev parent reply other threads:[~2009-03-02 21:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-01 18:40 [PATCH 1/1] vt: add ioctl commands to /dev/vcsaX to get/put the current palette of the given tty Cedric Roux
2009-03-02 21:27 ` Andrew Morton [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=20090302132741.26eaf124.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=sed@free.fr \
--cc=viro@zeniv.linux.org.uk \
/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