linux-kernel - Re: [PATCH 1/2] USB: EHCI: Move sysfs related bits into ehci-sysfs.c

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]

Date:	Wed, 29 Jun 2011 14:51:42 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Kirill Smelkov <kirr@....spb.ru>
cc:	matt mooney <mfm@...eddisk.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] USB: EHCI: Move sysfs related bits into ehci-sysfs.c

On Wed, 29 Jun 2011, Kirill Smelkov wrote:

> Yes, but still it would be good to always keep the invariant
> 
>     allocated <= uframe_periodic_max
> 
> and that debug is there to catch when this breaks.

Then perhaps it should print out the maximum number of microseconds
already allocated for any uframe, instead of stopping as soon as it
finds something above the new limit.

> > Can you make that check conditional on DEBUG being set?
> 
> Yes I can, but it seems to me we are starting to complicate the code.
> 
> What's the problem with returning error on setting uframe_periodic_max <
> already allocated usb bandwith?

No problem, really.

> The checking is not a priority for me here, so if you think it's better not
> to check or do it under #ifdef - let's do it. Though of course we all
> have our preferences :)

Yes, it's just a matter of taste.  I prefer to add as little code as 
possible for a feature that won't be used much.

Alan Stern

--
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/