Re: contributing to linux kernel.

2009-10-03 Thread Martin Møller Skarbiniks Pedersen
2009/10/3 Davidlohr Bueso :
> On Wed, Sep 30, 2009 at 03:29:51PM +0530, Pete wrote:
>>
>> Hello list,
>>
>> I am interested towards contributing towards kernel in the form of
>> patches bug fixes or small enhancements to start off. I have completed
>> studying some of the pre-requisite books on kernel programming (RL,
>> UTLK3, some parts of LDD3 - as suggested on other newbie threads) and
>> also followed some of the threads which has enabled me to learn a lot
>> more.
>
> Kernel Janitors (http://kerneljanitors.org) is a good place to get your feet 
> wet, before you go into a more complex project (subsystem).

http://janitor.kernelnewbies.org/

Regards
Martin

--
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: facing a problem with irq handler,please help me

2009-10-03 Thread Pei Lin
2009/10/1 Harinderjit Singh Sandhu :
>
> this is the code for the small module that i wrote
> --
> --
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #define SKELETON_MAJOR 32
> #define SKELETON_NAME "skeleton"
> #define BASEPORT 0x378
> #define PARALLEL_PORT_INTERRUPT 7
> #define CASE1 1
> #define CASE2 2
> static int data;
> static unsigned int counter = 0;
> static char string [128];
> static int data;
> //static int interruptcount = 0;
>
> DECLARE_WAIT_QUEUE_HEAD(skeleton_wait);
> static int data_not_ready = 1;
>
> // open function - called when the "file" /dev/skeleton is opened in
> userspace
> static int skeleton_open (struct inode *inode, struct file *file) {
>     printk("skeleton_open\n");
>     // we could do some checking on the flags supplied by "open"
>     // i.e. O_NONBLOCK
>     // -> set some flag to disable interruptible_sleep_on in skeleton_read
>     return 0;
> }
>
> // close function - called when the "file" /dev/skeleton is closed in
> userspace
> static int skeleton_release (struct inode *inode, struct file *file) {
>     printk("skeleton_release\n");
>     return 0;
> }
>
> // read function called when from /dev/skeleton is read
> static ssize_t skeleton_read (struct file *file, char *buf,
>         size_t count, loff_t *ppos) {
>     int len, err;
>
>     // check if we have data - if not, sleep
>     // wake up in interrupt_handler
>     while (data_not_ready) {
>         interruptible_sleep_on(&skeleton_wait);
>     }
>     data_not_ready = 1;
>     printk("read works fine");
>     if( counter <= 0 )
>         return 0;
>     err = copy_to_user(buf,string,counter);
>     if (err != 0)
>         return -EFAULT;
>     len  = counter;
>     counter = 0;
>     return len;
> }
>
> // write function called when to /dev/skeleton is written
> static ssize_t skeleton_write (struct file *file, const char *buf,
>         size_t count, loff_t *ppos) {
>     int err;
>     printk("write works fine");
>     err = copy_from_user(string,buf,count);
>     if (err != 0)
>         return -EFAULT;
>     counter += count;
>     return count;
> }
>
> // ioctl - I/O control
> static int skeleton_ioctl(struct inode *inode, struct file *file,
>         unsigned int cmd, unsigned long arg) {
>     int retval = 0;
>     switch ( cmd ) {
>         case CASE1:/* for writing data to arg */
>             if (copy_from_user(&data, (int *)arg, sizeof(int)))
>             return -EFAULT;
>             break;
>         case CASE2:/* for reading data from arg */
>             if (copy_to_user((int *)arg, &data, sizeof(int)))
>             return -EFAULT;
>             break;
>         default:
>             retval = -EINVAL;
>     }
>     return retval;
> }
>
> // interrupt handler
> irqreturn_t interrupt_handler (int irqn, void *dev)
> {
>
>     printk("Press a key  ");
>
>
>     return IRQ_HANDLED;
>
>
> }
>
> // define which file operations are supported
> struct file_operations skeleton_fops = {
>     .owner    =    THIS_MODULE,
>
>     .read        =    skeleton_read,
>     .write    =    skeleton_write,
>
>     .ioctl    =    skeleton_ioctl,
>
>     .open        =    skeleton_open,
>
>     .release    =    skeleton_release,
>
> };
>
> // initialize module (and interrupt)
> static int __init skeleton_init_module (void) {
>     int i;
>     int ret;
>     printk("initializing module\n");
>     //free_irq(7,NULL);
>     i = register_chrdev (SKELETON_MAJOR, SKELETON_NAME, &skeleton_fops);
>     if (i != 0) return - EIO;
>     //disable_irq(7);

>     ret = request_irq (7, interrupt_handler,0,SKELETON_NAME ,NULL);

first, the flags using the macro which kernel provides is a good idea.
If your flag indicate the SA_SHIRQ,
means your irq share one interrupt line. SO your interrupt handler
must check your interrupt status registers,and interrupt control
registers,make sure it is your hardware interrupt. for the
common,after your handling routine,u should clean the interrupt status
register. and wait next interrupt or disable the interrupt.

>     printk("ret=%d\n",ret);
>     //enable_irq(7);
>     if(ret>=0){
>     enable_irq(7);
> //    outb_p(0x10, BASEPORT + 2);
>     }
>     else
>     {
>     printk("Not Working \n");
>     }
>     //printk("Generating interrupt \n");
>
>     /*outb(0, BASEPORT);
>     outb(255, BASEPORT);
>     outb(0, BASEPORT);*/
>     printk("Interrupt generated. You should see the handler-message\n");
>
>     return 0;
> }
>
> // close and cleanup module
> static void __exit skeleton_cleanup_module (void) {
>     printk("cleaning up module\n");
>     unregister_chrdev (SKELETON_MAJOR, SKELETON_NAME);
>     //disable_irq(6);
>     //free_irq(6, NULL);
> }
>
> module_init(skeleton_init_module);
> module_exit(skeleton_cleanup_module);
>
> MODULE_LICENSE("GPL");
> 
>
>
> and a

Re: loading a kernel image on arm processor

2009-10-03 Thread vinit dhatrak
On Sat, Oct 3, 2009 at 7:51 PM, Harinderjit Singh Sandhu
 wrote:
> hello list
>
>
> i think it is possible to load a kernel image to arm processor. actually my
> friend and i have planned to load kernel image on ARM processor and then
> write some drivers (especially sound) for that. i guess this is feasible,
> but if its not please give your precious inputs on that. and any other
> suggestion on this are welcome
> Thanks
>
> Harinderjit Singh
>

Hi Harinderjit,

Linux kernel is well ported for ARM arch. If you want to build a
kernel image for ARM then search for cross-compile linux for arm, you
will get exact steps. Actually Fedora is already putting some efforts
towards better arm support as a whole distribution, please take a look
at
http://fedoraproject.org/wiki/Architectures/ARM
http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu

-Vinit

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



sk_buff off by one confusion

2009-10-03 Thread Michael Blizek
Hi!

I am programming a layer 3/4 protocol (source is available at
michaelblizek.twilightparadox.com). It does something like this.

static int rcv(struct sk_buff *skb, struct net_device *dev,
struct packet_type *pt, struct net_device *orig_dev)
{
char *packet_type_p;

printk(KERN_ERR "rcv 2 %d", (int) skb);

packet_type_p = skb_pull(skb, 1);

printk(KERN_ERR "header %d", (int) packet_type_p);
printk(KERN_ERR "data %d", (int) skb->data);
printk(KERN_ERR "len %d", (int) skb->len);
printk(KERN_ERR "nhdr %d", (int) skb_network_header(skb));
}

static struct packet_type ptype_cor = {
.type = htons(ETH_P_COR),
.dev = 0,
.func = rcv
};

int __init cor_rcv_init(void)
{
BUG_ON(sizeof(struct skb_procstate) > 48);
dev_add_pack(&ptype_cor);
return 0;
}

I know, converting void* to int only works on 32 bit systems. I did this the
ugly way, because it is only for debugging and will be removed anyway.

The output is like this:
rcv 2 164120488
header 161199319
data 161199319
len 68
nhdr 161199318

The interesting part is that skb_network_header is correct and both skb_pull
and skb->data points one byte after the start of the packet. I thought
that skb->data should always point to the start of the packet and that
skb_pull should point to the network header after rcv is called!? ipv4 uses
skb_network_header and runs fine...

The device which sent the packet was the user mode linux switch daemon (see
http://user-mode-linux.sourceforge.net/old/networking.html).

-Michi


--
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: Search module in linux

2009-10-03 Thread askb

> module for every filesytem. I feel looking at the codes may help me
> appreciate the filesystems better. I searched the kernel tree and even
> googled for such code, but I feel I am yet not proficient enough to
> get anything. Hope you guys can help me out.
To start off, I would suggest the run a strace of a simple `find .` just
to get a trace of the system calls.
Then look into vfs_read() {VFS} -> ext3/4 operation (depending on the
your logical FS) looking the specific implementation. Then optionally
you could look into some of the block device operations.

-Anil


--
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: Search module in linux

2009-10-03 Thread Manish Katiyar
On Sat, Oct 3, 2009 at 8:29 PM, Deepak Mishra  wrote:
> Hello everyone,
>                          I am very new to this list and kernel programming.
> Maybe this is too early, but I am actually interested in knowing the file
> search module (inherently the source code for "find" program) in linux

Hi Deepak,

"find" is a userspace program and there is no kernel component in it.

> filesystem. I believe there would be seperate search module for every
> filesytem.

The only filesystem specific code which "find" needs to call is how to
traverse directories, and how to get the file names given that each
filesystem will have its own layout. However this is abstracted using
the syscall readdir(). so you don't need to worry about the underlying
layout of the filesystem. You can look at ext2_readdir() for example .

> I feel looking at the codes may help me appreciate the
> filesystems better. I searched the kernel tree and even googled for such
> code, but I feel I am yet not proficient enough to get anything. Hope you
> guys can help me out.

You can try to write your own "find" program in userspace. See the
usage of following syscalls.
readdir(), opendir()

Best of luck.

Thanks -
Manish


> Thanks in anticipation,
> Deepak Mishra



-- 
Thanks -
Manish

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



Search module in linux

2009-10-03 Thread Deepak Mishra
Hello everyone,
 I am very new to this list and kernel programming.
Maybe this is too early, but I am actually interested in knowing the file
search module (inherently the source code for "find" program) in linux
filesystem. I believe there would be seperate search module for every
filesytem. I feel looking at the codes may help me appreciate the
filesystems better. I searched the kernel tree and even googled for such
code, but I feel I am yet not proficient enough to get anything. Hope you
guys can help me out.
Thanks in anticipation,
Deepak Mishra


loading a kernel image on arm processor

2009-10-03 Thread Harinderjit Singh Sandhu
hello list


i think it is possible to load a kernel image to arm processor. actually my
friend and i have planned to load kernel image on ARM processor and then
write some drivers (especially sound) for that. i guess this is feasible,
but if its not please give your precious inputs on that. and any other
suggestion on this are welcome
Thanks

Harinderjit Singh