linux-kernel - Re: [PATCH 4/4] [RFC] UIO: generic platform driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080411104154.GA18986@digi.com>
Date:	Fri, 11 Apr 2008 12:41:54 +0200
From:	Uwe Kleine-König <Uwe.Kleine-Koenig@...i.com>
To:	"Hans J. Koch" <hjk@...utronix.de>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] [RFC] UIO: generic platform driver

Hello Hans,

Hans J. Koch wrote:
> On Fri, Apr 11, 2008 at 08:21:06AM +0200, Uwe Kleine-König wrote:
> > > > +	for (i = 0; i < pdev->num_resources; ++i) {
> > > > +		struct resource *r = &pdev->resource[i];
> > > 
> > > Please don't define new variables in the middle of a function.
> > This is a matter of taste.  In my eyes it's better to declare it here
> > because then it's easier to see where it's used.
> 
> No. It's more important to see which variables are declared in the
> function and which are declared elsewhere. If you have to search the
> whole body of a function for possible declarations, this is BAD. And if
> it's not clear where a variable is used, the function is too long or has
> other style problems. Your function is short and clean, so where's the
> problem? Please move the declaration to the top of the function.
I'm not conviced and still prefer it that way.  I gave way for your
requests in uio.c because it's your code.  I want to leave it as it is
and hope you will accept that (as this is my code).

> > BTW would you be open to redefine uio_info as:
> > 
> > 	struct uio_info {
> > 		struct uio_device       *uio_dev;
> > 		...
> > 		size_t			num_memmaps;
> > 		struct uio_mem		mem[];
> > 	}
> > 
> > This allows to allocate exactly the number of members in the mem array
> > that are needed (for the cost of a size_t).  (You just do:
> > 
> > 	uio_info uioinfo = kzalloc(sizeof(*uioinfo) + num_memmaps * sizeof(uioinfo->mem[0]), GFP_KERNEL);
> > 
> > it's still one chunk of memory and usage is similar---just with
> > MAX_UIO_MAPS substituted by uioinfo->num_memmaps.)
> 
> I don't like it. It makes things more complicated without any obvious
> gain.
Most use cases I imagine only use a single mapping, so the gain would be
to save 4 (or later more) 'struct uio_mem's per device.

>       sizeof(struct uio_info) would return wrong values,
For which definition of wrong?  sizeof(struct uio_info) don't include
space for mem then, but in my eyes that's correct.  Having to care about
the size of mem is the burden when it's not constant.

>                                                          you need to
> free the extra memory,
There is no extra memory because uioinfo and it's mem member are
allocated together with a single kzalloc (and must be).  (Thats the
difference to

	struct uio_info {
		...
		size_t			num_memmaps;
		struct uio_mem		*mem;
	};

.)
>                        userspace applications need to be able to deal
> with 10000 mappings...
For the userspace it's exactly the same, isn't it?

Best regards
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/