linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Knorr <kraxel@bytesex.org>
To: Michael Hunold <hunold@convergence.de>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [RFC][2.5] generic_usercopy() function (resend, forgot the patches)
Date: Fri, 23 May 2003 13:49:59 +0200	[thread overview]
Message-ID: <20030523114959.GA7081@bytesex.org> (raw)
In-Reply-To: <3ECDF3B1.8090902@convergence.de>

> >>+generic_usercopy(struct inode *inode, struct file *file,

> >The name is a bit mislead.  maybe ioctl_usercopy?  ioctl_uaccess?
> 
> These are both fine IMHO.

I'd pick ioctl_usercopy() because the name is much like
the well-known copy_(from|to)_user functions.

> >Also file/inode should go away from the prototype (and the callback).
> >Only file is needed because inode == file->f_dentry->d_inode, and even
> >that one should be just some void *data instead.
> 
> I only copied the function from videodev.c and renamed it, so please 
> don't blame me for the way stuff is done there. 8-)

I've just pass through what the fops->ioctl() function is called with.
Sure file* is enougth?  If so, why the fops->ioctl() function is called
with both file and inode?

I think my v4l drivers just need file->priv_data (havn't looked at the
code through), so some void *data would work equally well for them.

> >>+	case _IOC_READ: /* some v4l ioctls are marked wrong ... */
> >That's crap.  Please move this workaround to v4l not into generic code.
> 
> Is it possible to fix the definitons of the v4l ioctls instead without 
> breaking binary compatiblity?

Not trivial.  You'll have to support both old and new (fixed) ioctl
numbers, otherwise you'll break existing binaries.  Using the new ones
internally and mapping the old to the new ones somehow might work.

> >>+	case _IOC_WRITE:
> >>+	case (_IOC_WRITE | _IOC_READ):
> >>+		if (_IOC_SIZE(cmd) <= sizeof(sbuf)) {
> >>+			parg = sbuf;
> >>+		} else {
> >>+			/* too big to allocate from stack */
> >>+			mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
> >>+			if (NULL == mbuf)
> >>+				return -ENOMEM;
> >>+			parg = mbuf;
> >
> >
> >I wonder whether you should just kmalloc always. 

Point of implementing it this way is that (a) the kmalloc()/kfree()
isn't for free and (b) we shouldn't use plenty of stack memory.  So
using kmalloc for big chunks and allocate from stack for the small ones
looks like a good compromise to me.

> Since this function is always used in user context and the memory is 
> always freed afterwards, it should be possible to use vmalloc() or a 
> static buffer (what's the maximum size?) instead.

static buffer?  You are kidding, are you?

  Gerd

-- 
sigfault

  parent reply	other threads:[~2003-05-23 12:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-23  9:37 [RFC][2.5] generic_usercopy() function (resend, forgot the patches) Michael Hunold
2003-05-23  9:47 ` Christoph Hellwig
2003-05-23 10:10   ` Michael Hunold
2003-05-23 10:19     ` Christoph Hellwig
2003-05-23 11:49     ` Gerd Knorr [this message]
2003-05-25 11:23   ` David Woodhouse
2003-05-23 11:17 ` Ingo Oeser
2003-05-30  0:25 ` David Wagner

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=20030523114959.GA7081@bytesex.org \
    --to=kraxel@bytesex.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=hch@infradead.org \
    --cc=hunold@convergence.de \
    --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;
as well as URLs for NNTP newsgroup(s).