code questions
Bill Cunningham
one is having to copy this code write their own version of what is written
here.
http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/node17.html
http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/node16.html
This first url I have posted before and I have learned it is a type of
faux OOP attempt. What about the second bit of code? Am I looking at a model
that one would write or actual prototype of a USB ?
Bill
Michael Foukarakis
> I am looking at this code and I can't tell if prototypes are listed or
> one is having to copy this code write their own version of what is written
>
> This first url I have posted before and I have learned it is a type of
> faux OOP attempt. What about the second bit of code? Am I looking at a model
> that one would write or actual prototype of a USB ?
>
> Bill
The 2nd bit of code is the definition of a structure that identifies a
USB interface driver to usbcore. It's an excerpt from the Linux kernel
source code (usb.h). So, the answer to your question is the set of
operations a USB interface driver should support - together with some
information about it blahblahblah.
What does the first link has to do with OOP? I don't see it.
Bill Cunningham
"Michael Foukarakis" <electr...@gmail.com> wrote in message
news:e826b8ce-f5c3-4bb1...@q4g2000yqm.googlegroups.com...
It's some rather odd looking C. Here...
void * (*probe)(struct usb_device*,unsigned int,const struct usb_device_id
*id_table);
Bill
Keith Thompson
[...]
> The 2nd bit of code is the definition of a structure that identifies a
> USB interface driver to usbcore. It's an excerpt from the Linux kernel
> source code (usb.h). So, the answer to your question is the set of
> operations a USB interface driver should support - together with some
> information about it blahblahblah.
>
> What does the first link has to do with OOP? I don't see it.
No, actually Bill didn't write that; Michael Foukarakis did. Bill
wrote the following, but it's not differentiated from the quoted text
from Michael in any way.
> It's some rather odd looking C. Here...
>
> void * (*probe)(struct usb_device*,unsigned int,const struct usb_device_id
> *id_table);
Bill, please fix your newsreader so it quotes properly (google
"OE-Quotefix"), or find a different one; there are plenty of free ones
out there.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Bill Cunningham
"Keith Thompson" <ks...@mib.org> wrote in message
news:ln7hrss...@nuthaus.mib.org...
> Bill, please fix your newsreader so it quotes properly (google
> "OE-Quotefix"), or find a different one; there are plenty of free ones
> out there.
I slipped up again. I can for the most part seem to cut these messages
and trim correctly. But this time I wanted to leave everything that was said
intact. I must not be doing that correctly manually. Does this quotefix
affect emails? I just want something that helps trim usenet posts.
Bill
Bill Cunningham
Ian Collins
>
> It's some rather odd looking C. Here...
>
> void * (*probe)(struct usb_device*,unsigned int,const struct usb_device_id
> *id_table);
What's odd about a function pointer member?
--
Ian Collins
Keith Thompson
> On 1/8/2010 2:36 PM, Bill Cunningham wrote:
>> "Keith Thompson"<ks...@mib.org> wrote in message
>> news:ln7hrss...@nuthaus.mib.org...
>>> Bill, please fix your newsreader so it quotes properly (google
>>> "OE-Quotefix"), or find a different one; there are plenty of free ones
>>> out there.
>>>
>> I slipped up again. I can for the most part seem to cut these messages
>> and trim correctly. But this time I wanted to leave everything that was said
>> intact. I must not be doing that correctly manually. Does this quotefix
>> affect emails? I just want something that helps trim usenet posts.
>>
Yes, it's right, but that doesn't necessarily prove anything. The
problem seems to occur only for responses to some articles, depending
on how the parent article was posted. (I don't remember the details.)
But as far as I know Thunderbird doesn't have the problem. If you can
consistently use Thunderbird to post here, that should solve it.
Thanks!
Bill Cunningham
> Yes, it's right, but that doesn't necessarily prove anything. The
> problem seems to occur only for responses to some articles, depending
> on how the parent article was posted. (I don't remember the details.)
>
> But as far as I know Thunderbird doesn't have the problem. If you can
> consistently use Thunderbird to post here, that should solve it.
>
> Thanks!
Here's something else I've seen in standard C this is cut from usb.c in
the 2.4 linux kernel.
static __inline__ void wait_ms(unsigned int ms)
{
if(!in_interrupt()) {
current->state = TASK_UNINTERRUPTIBLE;
schedule_timeout(1 + ms * HZ / 1000);
}
else
mdelay(ms);
}
if (!in_interrupt())
I have seen this in switch staements and with if as the example shows. I am
using professional code reinforce learning. The only part I don't quite get
is the ! part. The rest of the code is legible to me.
Bill
Bill Cunningham
"Ian Collins" <ian-...@hotmail.com> wrote in message
news:7qphgf...@mid.individual.net...
> What's odd about a function pointer member?
What function? What's the name of this function? probe is declared and
must be defined somewhere else but not here I get,
void **probe... and so on. That's a prototype or definition. But void
*(*probe)... What's the purpose of use here?
Bill
Ian Collins
>
> Here's something else I've seen in standard C this is cut from usb.c in
> the 2.4 linux kernel.
>
> static __inline__ void wait_ms(unsigned int ms)
That's not "standard C".
> {
> if(!in_interrupt()) {
> current->state = TASK_UNINTERRUPTIBLE;
> schedule_timeout(1 + ms * HZ / 1000);
> }
> else
> mdelay(ms);
> }
>
> if (!in_interrupt())
>
> I have seen this in switch staements and with if as the example shows. I am
> using professional code reinforce learning. The only part I don't quite get
> is the ! part. The rest of the code is legible to me.
An old Linux kernel is not "professional code". The Linux kernel is
written mainly in (often arcane) GNU C, so it's not the best learning
source.
What does your C book tell you about the ! operator?
--
Ian Collins
Ian Collins
> "Ian Collins" <ian-...@hotmail.com> wrote in message
> news:7qphgf...@mid.individual.net...
>
>> What's odd about a function pointer member?
>
> What function? What's the name of this function? probe is declared and
> must be defined somewhere else but not here I get,
Who said function? I said that
void * (*probe)(struct usb_device*,unsigned int,const struct
usb_device_id *id_table);
is a function pointer member of the struct declared in the code you linked.
> void **probe... and so on. That's a prototype or definition. But void
> *(*probe)... What's the purpose of use here?
You appear to be studying code you are not ready to study yet. Maybe if
they had written:
typedef void* (*probeFn)(struct usb_device*,unsigned int,const struct
usb_device_id*);
...
struct usb_driver {
...
probeFn probe;
...
};
things would have been clearer?
This is pretty common stuff for device driver interfaces.
--
Ian Collins
Bill Cunningham
[snip]
> ...
> struct usb_driver {
> ...
> probeFn probe;
> ...
> };
>
> things would have been clearer?
>
> This is pretty common stuff for device driver interfaces.
Oh yes that's much better.
Bill
Bill Cunningham
the book again tomorrow.
Bill
Keith Thompson
> On 1/8/2010 3:46 PM, Ian Collins wrote:
>> What does your C book tell you about the ! operator?
>>
> I couldn't fidn it in kandr2's index. I will do a web search or check
> the book again tomorrow.
Look on page 263 (the first page of the index), about 2/3 of the way
down the first column, between "&&" and "||".
Nick
That whole piece of code has been written in a style I quite like that
makes it read as near-English, or at least pseudo code.
If goes something like this:
If not in an interrupt
make the current state "uninterruptible"
schedule a timeout in ms milliseconds
otherwise
wait ms miliseconds
A really good example of how careful chosen function and variable names plus
use of good named "constants" etc can make code that I've never seen
before completely legible.
! before in_interrupt is far better in this case than, say
if(in_interrupt == false)
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Bill Cunningham
> Look on page 263 (the first page of the index), about 2/3 of the way
> down the first column, between "&&" and "||".
Aha. a logical not then. I was confusing it with != when if (!something)
is more like if (||something).
Bill
Keith Thompson
Yes, it's logical not.
!= is in equality; it's a single token, obviously inspired by the use
of "!" to mean negation, but defined by itself.
"if (||something)" doesn't make any sense; I have no idea what point
you're trying to make by mentioning it.