Re: usb driver binding to the device
The newer _Essential Linux Device Drivers_ book by Venkiteswaran has long, detailed chapters about PCI, USB, serial and network devices, all with detailed example code. -- Alison Chaiken (650) 279-5600 (cell) http://www.exerciseforthereader.org/ The only real deadline in life is the one where you actually die. -- Eliot D. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: difference between read permission and executing permission
On Sun, Sep 12, 2010 at 9:07 PM, Parmenides wrote: > 2010/9/12 Mulyadi Santosa : >> On Sun, Sep 12, 2010 at 00:28, Parmenides >> wrote: >>> Hi, >>> >>> For a specified directory, we can go through it when the kernel >>> parsing path, though we can not read it. Actually, parsing path also >>> need read the directory file. So, how does the kernel distinguish >>> between these two permission? >> > Sorry for replying so late due to some trifles. For a directory, if it > is allowed to read, that means we can list all items in its directory > file, namely that we can read it completely. May be I understood the question wrong but you can't "ls" in a directory if it doesn't have execute permission. Or rather even if a directory has read/exectue permission you can't ls on it till all the directories in its path have execute permission. Is there something else that you are asking ? /home/mkatiyar/codetree/main> cd /tmp /tmp> mkdir -p a/b/c/d /tmp> ls -lR a a: total 4 drwxr-xr-x 3 mkatiyar mkatiyar 4096 2010-09-12 22:26 b a/b: total 4 drwxr-xr-x 3 mkatiyar mkatiyar 4096 2010-09-12 22:26 c a/b/c: total 4 drwxr-xr-x 2 mkatiyar mkatiyar 4096 2010-09-12 22:26 d a/b/c/d: total 0 /tmp> chmod 000 a/b /tmp> ls -lR a a: total 4 d- 3 mkatiyar mkatiyar 4096 2010-09-12 22:26 b ls: cannot open directory a/b: Permission denied /tmp> cd a/b ksh: cd: a/b: [Permission denied] /tmp> ls a/b ls: cannot open directory a/b: Permission denied > If it is allowed to > execute, that means we can go through it in a process of path parsing. > Path parsing will open every directory in a specified path. For > example, when parsing a path like /home/parmenides/src/hello.c, the > kernel will open a sequence of directory files, namely /, /home, > /home/parmenides and /home/parmenides/src, and read its subdirectory > for each. So, both of read permission and executing permission mean > that the kernel need to read the corresponding directory file. As > such, the common 'readable' has two meanings for a directory. One > corresponds to read the directory file when listing it, the other > corresponds to read the directory file when paring path. > > On the other hand, system call opendir(const char *pathname) has no > way to distinguish these two meanings whereas both listing and path > parsing need call opendir(). My quesition is exactly that how these > two permissions take their effect. > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecar...@nl.linux.org > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Thanks - Manish == [$\*.^ -- I miss being one of them == -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: difference between read permission and executing permission
2010/9/12 Mulyadi Santosa : > On Sun, Sep 12, 2010 at 00:28, Parmenides wrote: >> Hi, >> >> For a specified directory, we can go through it when the kernel >> parsing path, though we can not read it. Actually, parsing path also >> need read the directory file. So, how does the kernel distinguish >> between these two permission? > Sorry for replying so late due to some trifles. For a directory, if it is allowed to read, that means we can list all items in its directory file, namely that we can read it completely. If it is allowed to execute, that means we can go through it in a process of path parsing. Path parsing will open every directory in a specified path. For example, when parsing a path like /home/parmenides/src/hello.c, the kernel will open a sequence of directory files, namely /, /home, /home/parmenides and /home/parmenides/src, and read its subdirectory for each. So, both of read permission and executing permission mean that the kernel need to read the corresponding directory file. As such, the common 'readable' has two meanings for a directory. One corresponds to read the directory file when listing it, the other corresponds to read the directory file when paring path. On the other hand, system call opendir(const char *pathname) has no way to distinguish these two meanings whereas both listing and path parsing need call opendir(). My quesition is exactly that how these two permissions take their effect. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: hello world module error
On Mon, Sep 13, 2010 at 6:47 AM, Mulyadi Santosa wrote: > to dig further by your own. Hint: use make V=1 > > > yes the directory name had a blank space
Re: Regarding Signals in Kernel
Hi On Mon, Sep 13, 2010 at 01:22, Dave Hylands wrote: > Hi Sri, > > On Sun, Sep 12, 2010 at 10:02 AM, Sri Ram Vemulpali > wrote: >> Hi Guys, >> This is the question asked by WindRiver.com in interview. >> Question: A process has 5 children. Process child 5 is trying to send >> signal (some signal) to Child 2 and Child 3. Calls signal(2,SIG), >> signal(3,SIG). Now the question is, How are the signals delivered, I mean >> their order and which child process gets the signal first. > > It is my understanding that signals are delivered when a process makes > the kernel-space to user-space transition (say on a system call). So > which one will be called first depends on which child makes the next > system call. AFAIK, signal set on target task_struct can be modified anytime. Then, on the next nearest context switch (AFAIK: interrupt to kernel mode, interrupt to user mode and so on) ...due to the raised re-scheduling request most of times (I really become rusty here), next process is picked. If it is the one that has the signal queued, its signal set is checked for any waiting signal. Depending the signal and the setup of handler, it could be handled in kernel space right away before rising up to user mode. Or it could be...I call it, "blitzkrieg mode", jump fast to user mode, execute the user mode handler (in the case there's custom handler installed), fall back again to kernel mode. So as you can see briefly above, signal could be delivered anytime, but you can't really tell when it would be picked. Nasty, yes...this is a non real time OS anyway :D >> I know that if you use real time signals they are delivered in order and >> accounts for number of times signals are delivered, this is in threads. But >> when it comes process, a process can not send signals to its own group in >> linux kernel. >> So can anyone please clarify this, what is the right scenario. > > I'm not familiar enough with the distinctions to provide any more detail here. > > I don't see any reason why a process can't signal itself, but this is > just an opinion, not backed up by any fact or experiment. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecar...@nl.linux.org > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: hello world module error
Hi... On Sun, Sep 12, 2010 at 23:34, Bond wrote: > I created a small hello world module for programming > > make -C /lib/modules/2.6.32-24-generic/build M=/home/bond/rrr modules > make[1]: Entering directory `/usr/src/linux-headers-2.6.32-24-generic' > make[1]: *** No rule to make target `rrr'. Stop. Something is wrong, your "rrr" directory is interpreted as "make target" instead of directory. I can't tell for sure, so you might try to dig further by your own. Hint: use make V=1 -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: a problem in a character driver code
Ok by now I have been able to fix this problem.
1) config.h has been dropped from 2.6.19 series of kernels so that was one
error
2) the program was kept in a directory whose directory name had a blank
space in between this was also giving me errors
3) I had tried the functions with my name rather than
memory_open,memory_read,memory_release
I am not clear if this type of use is wrong.
On Sun, Sep 12, 2010 at 7:52 PM, Bond wrote:
> =
>
>
>
> /* Necessary includes for device drivers */
> #include
> #include
>
config.h has been dropped from 2.6.19 series of kernels so that was one
error
> #include
> #include /* printk() */
> #include /* kmalloc() */
> #include /* everything... */
> #include /* error codes */
> #include /* size_t */
> #include
> #include /* O_ACCMODE */
> #include /* cli(), *_flags */
> #include /* copy_from/to_user */
>
>
> /* Declaration of memory.c functions */
> int bond_open(struct inode *inode, struct file *filp) { return 0;};
>
I had tried the functions with my name rather than
memory_open,memory_read,memory_release
I am not clear if this type of use is wrong.
The driver is working but it if I do
echo -n abcdefg > /dev/memory
then on doing cat /dev/memory
only last g is coming and all previous words which I gave abcdef are
dropped out
any idea on what might be the error.
Re: Regarding Signals in Kernel
Hi Sri, On Sun, Sep 12, 2010 at 10:02 AM, Sri Ram Vemulpali wrote: > Hi Guys, > This is the question asked by WindRiver.com in interview. > Question: A process has 5 children. Process child 5 is trying to send > signal (some signal) to Child 2 and Child 3. Calls signal(2,SIG), > signal(3,SIG). Now the question is, How are the signals delivered, I mean > their order and which child process gets the signal first. It is my understanding that signals are delivered when a process makes the kernel-space to user-space transition (say on a system call). So which one will be called first depends on which child makes the next system call. > I know that if you use real time signals they are delivered in order and > accounts for number of times signals are delivered, this is in threads. But > when it comes process, a process can not send signals to its own group in > linux kernel. > So can anyone please clarify this, what is the right scenario. I'm not familiar enough with the distinctions to provide any more detail here. I don't see any reason why a process can't signal itself, but this is just an opinion, not backed up by any fact or experiment. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Regarding Signals in Kernel
Hi Guys, This is the question asked by WindRiver.com in interview. Question: A process has 5 children. Process child 5 is trying to send signal (some signal) to Child 2 and Child 3. Calls signal(2,SIG), signal(3,SIG). Now the question is, How are the signals delivered, I mean their order and which child process gets the signal first. I know that if you use real time signals they are delivered in order and accounts for number of times signals are delivered, this is in threads. But when it comes process, a process can not send signals to its own group in linux kernel. So can anyone please clarify this, what is the right scenario. Thanks, Sri.
Re: Shared Interrupt Lines [was IRQ_NONE or IRQ_HANDLED]
On Sun, 2010-09-12 at 11:54 -0500, Josh Cartwright wrote: > That's up for you, the driver writer, to decide. In your driver code > you are probably already keeping around a per-device object (that will > hold pointers to mapped registers, or other ways of communicating with > your device), so it makes sense in this case to request_irq() by passing > a pointer to that per-device object. In this way, your handler can > communicate with your device and ask it if it was the one that generated > the interrupt. Wow, very clear :) Thank you, -- Carlo -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Shared Interrupt Lines [was IRQ_NONE or IRQ_HANDLED]
On Sun, Sep 12, 2010 at 06:18:57PM +0200, Carlo Caione wrote: > > > That being said, the IRQ-core core does need some way to differentiate > > between handlers for shared IRQs. This is necessary so that you can > > selectively uninstall handlers. This is also why the free_irq() takes > > not only the IRQ#, but the dev_id (your dev1 or dev2) you registered > > with. > > I'm ok also with this point. But for example: > the IRQ-core code executes both the handlers for the shared irqn. > Just one of the handlers is the right one for that specific device, > whereas the other one should be return IRQ_NONE. Well, thats not _entirely_ true. It is possible that two devices sharing an IRQ can interrupt at the same time, so both handlers could return IRQ_HANDLED. :) > How do those parameters dev1 and dev2 help me within the handler > functions to know if the interrupt is coming from the right devices? That's up for you, the driver writer, to decide. In your driver code you are probably already keeping around a per-device object (that will hold pointers to mapped registers, or other ways of communicating with your device), so it makes sense in this case to request_irq() by passing a pointer to that per-device object. In this way, your handler can communicate with your device and ask it if it was the one that generated the interrupt. > I hope I'm not saying something stupid :) Not at all. -- -joshc -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
hello world module error
I created a small hello world module for programming
make -C /lib/modules/2.6.32-24-generic/build M=/home/bond/rrr modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-24-generic'
make[1]: *** No rule to make target `rrr'. Stop.
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-24-generic'
make: *** [build] Error 2
what could be the error
following is Makefile
ifeq ($(KERNELRELEASE),)
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
.PHONY: build clean
build:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
clean:
rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c
rm -rf modules.order Module.symvers
else
$(info Building with KERNELRELEASE =${KERNELRELEASE})
obj-m := program.o
endif
and following is the program
/* Necessary includes for device drivers */
#include
#include
#include /* printk() */
static int bond_init(void)
{
printk(KERN_ALERT "Hello, world\n");
return 0;
}
static void bond_exit(void)
{
printk (KERN_ALERT "Good by cruel world\n");
}
module_init(bond_init);
module_exit(bond_exit);
MODULE_AUTHOR("bond");
MODULE_LICENSE("GPL");
Re: Shared Interrupt Lines [was IRQ_NONE or IRQ_HANDLED]
On Sep 12, 2010, at 5:08 PM, Josh Cartwright wrote: > The provided dev pointer to request_irq() is not itself useful to the > core IRQ code, it doesn't do anything but store it away for use when > calling your handler function. Ok > That being said, the IRQ-core core does need some way to differentiate > between handlers for shared IRQs. This is necessary so that you can > selectively uninstall handlers. This is also why the free_irq() takes > not only the IRQ#, but the dev_id (your dev1 or dev2) you registered > with. I'm ok also with this point. But for example: the IRQ-core code executes both the handlers for the shared irqn. Just one of the handlers is the right one for that specific device, whereas the other one should be return IRQ_NONE. How do those parameters dev1 and dev2 help me within the handler functions to know if the interrupt is coming from the right devices? > Hopefully that answers your question. :) I hope I'm not saying something stupid :) -- Carlo Caione -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: usb driver binding to the device
On Sun, Sep 12, 2010 at 09:34:18PM +0530, Bond wrote: > On Sun, Sep 12, 2010 at 9:21 PM, Josh Cartwright wrote: > > > Again, you can look through the slides. Also you should read LDD3, as > > it covers alot of your questions. > > I am reading that book. > That book does talk about having a high level driver which is an > interface to the system calls but it does not talks about Bus Star > operations such as with different IO controllers on different > architectures. There are examples for interfacing with PCI, USB, and ISA devices (if I'm remembering correctly). Also, you have the source code to many, many existing drivers available to you in the kernel source tree if LDD3 is not enough. -- -joshc -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: usb driver binding to the device
On Sun, Sep 12, 2010 at 9:21 PM, Josh Cartwright wrote: > Again, you can look through the slides. Also you should read LDD3, as > it covers alot of your questions. > > I am reading that book. That book does talk about having a high level driver which is an interface to the system calls but it does not talks about Bus Star operations such as with different IO controllers on different architectures.
Re: usb driver binding to the device
On Sun, Sep 12, 2010 at 01:30:26PM +0530, Bond wrote:
> On Sat, Sep 11, 2010 at 11:31 PM, Josh Cartwright wrote:
>
> > To 'bind' to a device means that your driver is asserting control of the
> > device.
>
> You mean to say the driver is trying to take control of the device.
Yes. If your driver is bound to a device, it has exclusive control over
it.
> > On the previous slide, a USB device ID table was created that lists the
> > IDs of the devices the driver supports.
>
> Do you mean to say that it is possible that same driver support
> multiple devices?
> I have no clue of it.
Yes, it is quite common for a driver to control devices with different
IDs.
> > When your driver registers to
> > the USB core (via usb_register()),
>
> Can you point me which slide in the presentation I gave link is meaning this
> type of thing.
I only briefly looked at the presentation, I'd suspect its in there, but
I'm not going to look for it for you, you can manage that yourself.
> > the core code looks at the list of unclaimed devices and your
> > provided ID table and calls your probe() for any matches.
> >
> > Your probe() callback is responsible for returning 0 if it wants to
> > 'bind' to the device, otherwise you return an error.
> >
> Is 0 for success.
Yes.
> I see a structure
> static struct usb_driver {
> .owner :
> .name :
> .probe :
> .disconnect :
> .id_connect :
>
> }
> I am not clear as how this structure has mapped to functions.
You're responsible for populating the members of this structure with
your callback functions, and then passing it to usb_register().
> What my understanding of writing a device driver till now from my search on
> Internet is
>
> reserve a set of major and minor number
> define a file_operations structure associating to function pointers
> we need to define operations corresponding to system calls an application
> can apply
This would be enough for your driver to communicate to userspace, but it
is certainly not enough for your driver to communicate to your device
via usb.
> if I were to take above three points then on the link
> http://www.kroah.com/linux/talks/ols_2005_driver_tutorial/index.html
> which slide is doing that?
Again, you can look through the slides. Also you should read LDD3, as
it covers alot of your questions.
--
-joshc
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Shared Interrupt Lines [was IRQ_NONE or IRQ_HANDLED]
On Sun, Sep 12, 2010 at 02:45:15PM +0200, Carlo Caione wrote: > > Let's assume that I have registered two handlers on a shared IRQ. > > request_irq(irqn, handler1, IRQF_SHARED, "first", dev1); > request_irq(irqn, handler2, IRQF_SHARED, "second", dev2); > > using two different dev1 and dev2 device structures. > > When the interrupt is raised what is passed to handler1() and handler2() as > second > argument? dev1 is passed to handler1() and dev2 to handler2() or both receive > the > same value as pointer? Your handler1 will be called with dev1 as the second argument, and your handler2 will be called with dev2 as the second argument (but both will be called with the asserted IRQ as their first argument). > If each one receives the pointer to device structure indicated in > request_irq() > how this can help to differentiate between multiple device? The provided dev pointer to request_irq() is not itself useful to the core IRQ code, it doesn't do anything but store it away for use when calling your handler function. That being said, the IRQ-core core does need some way to differentiate between handlers for shared IRQs. This is necessary so that you can selectively uninstall handlers. This is also why the free_irq() takes not only the IRQ#, but the dev_id (your dev1 or dev2) you registered with. Hopefully that answers your question. :) -- -joshc -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Cairo cross compile
On Sun, Sep 12, 2010 at 4:33 AM, Giriprasad Deviprasad wrote: > export > LD_LIBRARY_PATH=/opt/asdlab/fontconfig/lib/:opt/asdlab/freetype/lib/:/opt/asdlab/atk/lib/:/opt/asdlab/glib/lib/:/opt/asdlab/pixman/lib/:/opt/asdlab/libxml2/lib/ > > Giri > > > How are you trying to compile Cairo? It looks like fontconfig and freetype > are both in a /opt/ directory, did you add these to your $LD_LIBRARY_PATH or > are you passing in the directories with the -L option to the gcc compiler? > > Danny G > > > Hmm... are you using pkg-config? What are the outputs of pkg-config --libs freetype2 pkg-config --libs fontconfig This is the program that the configure script uses to find out if the installed needed programs are the correct versions and where exactly they reside. This can be overridden by passing arguments into the configure script, but pkg-config is intended to make it a lot easier. It looks like you're installing packages into /opt/asdlab/ in their own subdirectory, so you'll probably have to modify the $PKG_CONFIG_PATH environment variable to point to each package's lib directory. Let me know if this helps at all Danny G
Shared Interrupt Lines [was IRQ_NONE or IRQ_HANDLED]
On Sep 11, 2010, at 11:58 PM, Josh Cartwright wrote: > Yes, if you have registered a handler on a shared IRQ, the first thing > your handler must do is determine if it was your device which generated > the interrupt. If it wasn't your device, you return IRQ_NONE. > > If you claim that you handled the interrupt by returning IRQ_HANDLED, > but you really didn't do anything, there are situations where you will > cause an interrupt storm and lock the system up tight (or at least one > processor). Consider the following scenario: > > 1. You've attached an interrupt to device A via request_irq(). > 2. Device A asserts the IRQ > 3. You're handler is called > 4. You don't quiesce the device, but you return IRQ_HANDLED > 5. The core code sees that that you returned IRQ_HANDLED, so assumes the >. device has unasserted the IRQ and unmasks the IRQ > 6. But the device is still asserting the IRQ! > 7. The IRQ core code jumps back to 3 > 8. ...lockup! > > Now, if you've attached yourself to a shared IRQ chain that contains a > legitimate handler for device A, you _might_ be okay returning > IRQ_HANDLED (because the core code will still continue down the chain > and call the real handler, which _will_ quiesce the device). But don't do > this. Especially if you register your registering your handler w/ > IRQF_SAMPLE_RANDOM, as you'll likely compromise the entropy of the > system. Let's assume that I have registered two handlers on a shared IRQ. request_irq(irqn, handler1, IRQF_SHARED, "first", dev1); request_irq(irqn, handler2, IRQF_SHARED, "second", dev2); using two different dev1 and dev2 device structures. When the interrupt is raised what is passed to handler1() and handler2() as second argument? dev1 is passed to handler1() and dev2 to handler2() or both receive the same value as pointer? If each one receives the pointer to device structure indicated in request_irq() how this can help to differentiate between multiple device? Thank you, -- Carlo Caione -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Cairo cross compile
export LD_LIBRARY_PATH=/opt/asdlab/fontconfig/lib/:opt/asdlab/freetype/lib/:/opt/asdlab/atk/lib/:/opt/asdlab/glib/lib/:/opt/asdlab/pixman/lib/:/opt/asdlab/libxml2/lib/ Giri How are you trying to compile Cairo? It looks like fontconfig and freetype are both in a /opt/ directory, did you add these to your $LD_LIBRARY_PATH or are you passing in the directories with the -L option to the gcc compiler? Danny G
Re: question about linked list implementation in kernel.h
On Sat, Sep 11, 2010 at 10:09 PM, Manish Katiyar wrote: > If you want some more details about this macro. > http://www.spinics.net/lists/linux-usb-devel/msg11766.html > > Thanks but Manohars explanation was perfect for newbies like me.
Re: usb driver binding to the device
On Sat, Sep 11, 2010 at 11:31 PM, Josh Cartwright wrote:
>
> To 'bind' to a device means that your driver is asserting control of the
> device.
You mean to say the driver is trying to take control of the device.
>
> On the previous slide, a USB device ID table was created that lists the
> IDs of the devices the driver supports.
Do you mean to say that it is possible that same driver support multiple
devices?
I have no clue of it.
> When your driver registers to
> the USB core (via usb_register()),
Can you point me which slide in the presentation I gave link is meaning this
type of thing.
> the core code looks at the list of
> unclaimed devices and your provided ID table and calls your probe() for
> any matches.
>
> Your probe() callback is responsible for returning 0 if it wants to
> 'bind' to the device, otherwise you return an error.
>
> Is 0 for success.
I see a structure
static struct usb_driver {
.owner :
.name :
.probe :
.disconnect :
.id_connect :
}
I am not clear as how this structure has mapped to functions.
What my understanding of writing a device driver till now from my search on
Internet is
reserve a set of major and minor number
define a file_operations structure associating to function pointers
we need to define operations corresponding to system calls an application
can apply
if I were to take above three points then on the link
http://www.kroah.com/linux/talks/ols_2005_driver_tutorial/index.html
which slide is doing that?
Re: difference between read permission and executing permission
On Sat, Sep 11, 2010 at 10:58 PM, Parmenides wrote: > Hi, > > For a specified directory, we can go through it when the kernel > parsing path, though we can not read it. Hi can you be a bit more elaborate on this part I am also trying to understand what you asked.
