Hi!
> > > What's the reason for this prejudice against C++-style comments in the
> > > kernel? I've never understood it... They seem so obviously useful,
> > > saving 3 characters of typing at the end of each comment line.
> >
> > I've never seen a piece of non-crappy code using them... that's
> > probably it. They tend to come from C++ and C++ code tends to be ****.
>
> That's understandable. I feel the same way about
> VeryLongAndHardToReadIdentifierNames.
:-).
> > ...or something like that. Or perhaps atomic_inc(), that should have
> > some barriers built-in.
>
> Yes, I did realize it. The reordering issues weren't important, as far as
> I can recall. Maybe the only reason I used those volatiles was for the
> implied compiler barriers; by now I've forgotten what the actual reasons
> were.
>
> It does deserve to be cleaned up. I'll go over the driver and get rid
> of those volatiles, or replace them with explicit barriers where needed.
>
> By the way, what brought on this sudden interest in g_file_storage?
I have sharp zaurus here, and would like to use its "usb gadget"
capability. g_file_storage seemed like obvious place to play with.
> In general, volatile is intended for use in a context where multiple
> entities (or a single multi-threaded processor) can operate simultaneously
> on the same data. It does not address all the issues involved because it
> ignores hardware-level CPU reordering effects. But it does act as a sort
> of permanent compiler barrier surrounding all uses of a data value.
> Those are the main reasons Alan Cox didn't like it: lack of low-level
> ordering and lack of selectivity (volatile is "always on").
It also does not work in cases where multiple accesses are needed for
single variable, and it has quite wrong semantic.
foo->data = "here are my data";
(volatile int) foo->done = 1;
...does not prevent data access to be moved around... It seems that
linux style
foo->data = "here are my data";
foo->done = 1;
mb();
1) actually works and 2) is closer to what people want.
Pavel
--
Thanks, Sharp!
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
