All of lore.kernel.org
 help / color / mirror / Atom feed
From: dean <dean@sensoray.com>
To: David Ellingsworth <david@identd.dyndns.org>
Cc: mchehab@infradead.org, laurent.pinchart@ideasonboard.com,
	isely@pobox.com, andre.goddard@gmail.com,
	linux-media@vger.kernel.org
Subject: Re: [PATCH] s2255drv: cleanup of driver disconnect code
Date: Tue, 30 Mar 2010 13:49:08 -0700	[thread overview]
Message-ID: <4BB263C4.4040900@sensoray.com> (raw)
In-Reply-To: <30353c3d1003300821n4b38f974w57ab6858252aa50f@mail.gmail.com>

Thanks for this and the other feedback.

The concern, without knowing the full history, is if video_device_alloc 
changes to do more than just allocate the whole structure with a single 
call to kzalloc?  Otherwise, why have this extra indirection and 
overhead in most V4L drivers?

The majority of V4L drivers are using video_device_alloc.  Very few 
(bw-qcam.h, c-qcam.c, cpia.h, pvrusb2, usbvideo) are using "struct 
video_device" statically similar to solution 1.  Three drivers(zoran, 
radio-gemtek, saa5249) are allocating their own video_device structure 
directly with kzalloc similar to solution #2.

The call definitely needs checked, but I'd like some more feedback on this.

Thanks and best regards,

Dean




David Ellingsworth wrote:
> This patch looks good, but there was one other thing that caught my eye.
>
> In s2255_probe_v4l, video_device_alloc is called for each video
> device, which is nothing more than a call to kzalloc, but the result
> of the call is never verified.
>
> Given that this driver has a fixed number of video device nodes, the
> array of video_device structs could be allocated within the s2255_dev
> struct. This would remove the extra calls to video_device_alloc,
> video_device_release, and the additional error checks that should have
> been there. If you'd prefer to keep the array of video_device structs
> independent of the s2255_dev struct, an alternative would be to
> dynamically allocate the entire array at once using kcalloc and store
> only the pointer to the array in the s2255_dev struct. In my opinion,
> either of these methods would be better than calling
> video_device_alloc for each video device that needs to be registered.
>
> Regards,
>
> David Ellingsworth
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2010-03-30 20:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-29 22:00 [PATCH] s2255drv: cleanup of driver disconnect code Dean A.
2010-03-30 15:21 ` David Ellingsworth
2010-03-30 20:49   ` dean [this message]
2010-03-30 21:09     ` Hans Verkuil
2010-03-30 21:36       ` Hans Verkuil

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=4BB263C4.4040900@sensoray.com \
    --to=dean@sensoray.com \
    --cc=andre.goddard@gmail.com \
    --cc=david@identd.dyndns.org \
    --cc=isely@pobox.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.