[lkml]   [2003]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: reducing stack usage in v4l?
On Wed, 5 Mar 2003 09:35:34 +0000
Russell King <> wrote:

| On Wed, Mar 05, 2003 at 10:15:52AM +0100, Gerd Knorr wrote:
| > But when looking at the disasm output it is obvious that it isn't true
| > (at least with gcc 3.2). On the other hand it is common practice in
| > many drivers, there must be a reason for that, no? Any chance this
| > used to work with older gcc versions?
| I don't believe so - I seem to remember looking at gcc 2.95 and finding
| the same annoying behaviour.

Yes, that's what I'm seeing with 2.96 as well.

| > Not sure what is the best idea to fix that. Don't like the kmalloc
| > idea that much. The individual structs are not huge, the real problem
| > is that many of them are allocated and only few are needed. Any
| > chance to tell gcc that it should allocate block-local variables at
| > the start block not at the start of the function?
| Not a particularly clean idea, but maybe creating a union of the
| structures and putting that on the stack? (ie, doing what GCC should
| be doing in the first place.)

That's an idea. Or make separate called functions for each ioctl and declare
the structures inside them?


Here are some v4l structure sizes from gcc 2.96 on a P4:

sizeof video_audio: 40
sizeof video_buffer: 20
sizeof video_capability: 60
sizeof video_channel: 48
sizeof video_mbuf: 136
sizeof video_mmap: 16
sizeof video_picture: 14
sizeof video_tuner: 52
sizeof video_window: 32
sizeof v4l2_audio: 52
sizeof v4l2_buffer: 68
sizeof v4l2_capability: 104
sizeof v4l2_control: 8
sizeof v4l2_fmtdesc: 64
sizeof v4l2_format: 204
sizeof v4l2_framebuffer: 44
sizeof v4l2_frequency: 44
sizeof v4l2_input: 76
sizeof v4l2_queryctrl: 68
sizeof v4l2_requestbuffers: 20
sizeof v4l2_tuner: 84
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.069 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site