From: Alan Stern on
On Tue, 20 Jul 2010, [utf-8] Michał Nazarewicz wrote:

> I wanted to keep fsg_string_serial_fill() as a macro so that it can
> use ARRAY_SIZE() on the first argument to check the size. If there
> was a single function it would have to explicitly take the length of
> the destination array as an argument -- that's what the *_n() function
> is for.
>
> The rationale is that not having to use ARRAY_SIZE() is, well,
> simpler. ;)

My advice is don't bother. Let callers give explicitly the size of
their buffer. How many other routines in the kernel do an implicit
ARRAY_SIZE on behalf of their callers? What if the buffer is passed as
a pointer instead of as an array?

> Basically, what you are proposing is to remove the
> fsg_string_serial_fill() macro and leave only the *_n() changed to
> an inline function and force all callers use sizeof/ARRAY_SIZE().

Or determine the size in some other way. Yes. (And then remove the
"_n" from the name since it will be unnecessary.)

> Am I getting that right? Personally, I'd leave things like they are
> changing the *_n() to a function. What do you think?

See above.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Brownell on


--- On Tue, 7/20/10, Michał Nazarewicz <m.nazarewicz(a)samsung.com> wrote:

> > Plus, you seem to be overlooking the basic need
> > (for userspace) to manage these IDs so they're
> > properly unique.  Two gadgets should never end
> up
> > using the same serial number.
>
> I'm not overlooking that.  I simply consider that a
> separate issue.
> Driver should provide some kind of default

It can't do that and guarantee uniqueness.
(Unless you consult the random number system,
which may not be available that early, and is
in any case not appropriate for this task.

Your concept is (still/again) broken.

(just like File
> Storage
> Gadget) and the fact that user space should
> override it is another
> matter in my opinion.

The value must come from userspace in the first
place, else it can't be correctly managed!!

>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Michał Nazarewicz on
>>> Plus, you seem to be overlooking the basic need
>>> (for userspace) to manage these IDs so they're
>>> properly unique. Two gadgets should never end
>>> up using the same serial number

> --- On Tue, 7/20/10, Michał Nazarewicz <m.nazarewicz(a)samsung.com> wrote:
>> I'm not overlooking that. I simply consider that a separate
>> issue. Driver should provide some kind of default.

On Tue, 20 Jul 2010 17:01:37 +0200, David Brownell <david-b(a)pacbell.net> wrote:
> It can't do that and guarantee uniqueness.

I never claimed otherwise.

> Your concept is (still/again) broken.

I don't buy that. The driver works better with a non-unique
serial number then without any. As such, a default serial
number should, in my opinion, be provided.

>> (just like File Storage Gadget) and the fact that user space
>> should override it is another matter in my opinion.

> The value must come from userspace in the first
> place, else it can't be correctly managed!!

I would say it *should* come from userspace but if userspace fails to
provide one *something* is better then *nothing*. I see how gadgets
should print a warning if serial is not provided from user space but
other then that I still think gadget should provide some value.

--
Best regards, _ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał "mina86" Nazarewicz (o o)
+----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/