Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame
Hi,
while in the pursuit of learning to understand assembly ..
This is my doubt ..Please help to understand
*I want to catch where in this disassembly call is made to get_sb function.*
Somehow in this disassembly, i m not finding, a direct *call* instruction,
with function name, written in english.
Hence, i m trying to interpret assembly and correlate with source code in C
line by line.
I have written my understanding in comments herewith assembly ..Kindly help
to correct
--
crash dis vfs_kern_mount
0x81183880 vfs_kern_mount:push %rbp
0x81183881 vfs_kern_mount+1: mov%rsp,%rbp
0x81183884 vfs_kern_mount+4: sub$0x40,%rsp
0x81183888 vfs_kern_mount+8: mov%rbx,-0x28(%rbp)
0x8118388c vfs_kern_mount+12: mov%r12,-0x20(%rbp)
0x81183890 vfs_kern_mount+16: mov%r13,-0x18(%rbp)
0x81183894 vfs_kern_mount+20: mov%r14,-0x10(%rbp)
0x81183898 vfs_kern_mount+24: mov%r15,-0x8(%rbp)
0x8118389c vfs_kern_mount+28: nopl 0x0(%rax,%rax,1)
0x811838a1 vfs_kern_mount+33: mov$0xffed,%rbx
0x811838a8 vfs_kern_mount+40: test %rdi,%rdi
0x811838ab vfs_kern_mount+43: mov%rdi,%r12
0x811838ae vfs_kern_mount+46: mov%esi,%r13d
0x811838b1 vfs_kern_mount+49: mov%rdx,%r14
0x811838b4 vfs_kern_mount+52: je 0x8118395b
vfs_kern_mount+219
0x811838ba vfs_kern_mount+58: mov%rdx,%rdi
0x811838bd vfs_kern_mount+61: mov%rcx,-0x38(%rbp)
IGNORING THE ABOVE TEXT FOR
NOW
0x811838c1 vfs_kern_mount+65: callq 0x811a1f60 *
alloc_vfsmnt*
0x811838c6 vfs_kern_mount+70: test %rax,%rax*should contain
mnt *
0x811838c9 vfs_kern_mount+73: mov%rax,%rbx
0x811838cc vfs_kern_mount+76: mov-0x38(%rbp),%rcx
0x811838d0 vfs_kern_mount+80: je 0x811839f0
vfs_kern_mount+368*goto out, if rax is 0 *
0x811838d6 vfs_kern_mount+86: test %rcx,%rcxif data is
false = 0
0x811838d9 vfs_kern_mount+89: je 0x811838e7
vfs_kern_mount+103*type-get_sb()*
0x811838db vfs_kern_mount+91: testb $0x2,0x8(%r12)r12
contains type
0x811838e1 vfs_kern_mount+97: je 0x811839b8
vfs_kern_mount+312*alloc_secdata*
0x811838e7 vfs_kern_mount+103:xor%r15d,%r15d
0x811838ea vfs_kern_mount+106:mov%rbx,%r8
0x811838ed vfs_kern_mount+109:mov%r14,%rdx
0x811838f0 vfs_kern_mount+112:mov%r13d,%esi
0x811838f3 vfs_kern_mount+115:mov%r12,%rdi
0x811838f6 vfs_kern_mount+118:callq *0x10(%r12)*
security_sb_copy_data
*
0x811838fb vfs_kern_mount+123:test %eax,%eax
0x811838fd vfs_kern_mount+125:js 0x81183990
vfs_kern_mount+272*goto out_free_secdata *
0x81183903 vfs_kern_mount+131:mov0x28(%rbx),%rax
0x81183907 vfs_kern_mount+135:test %rax,%rax
0x8118390a vfs_kern_mount+138:je 0x811839fc
vfs_kern_mount+380* get_sb*
0x81183910 vfs_kern_mount+144:orq
$0x2000,0x58(%rax)
0x81183918 vfs_kern_mount+152:mov%r15,%rdx
0x8118391b vfs_kern_mount+155:mov%r13d,%esi
0x8118391e vfs_kern_mount+158:mov0x28(%rbx),%rdi
0x81183922 vfs_kern_mount+162:callq 0x8121b9b0 *
security_sb_kern_mount*
IGNORING THE BELOW TEXT TOO
0x81183927 vfs_kern_mount+167:test %eax,%eax
0x81183929 vfs_kern_mount+169:jne0x81183978
vfs_kern_mount+248
0x8118392b vfs_kern_mount+171:mov0x28(%rbx),%rdi
0x8118392f vfs_kern_mount+175:mov0x28(%rdi),%r8
0x81183933 vfs_kern_mount+179:test %r8,%r8
0x81183936 vfs_kern_mount+182:js 0x81183a02
vfs_kern_mount+386
0x8118393c vfs_kern_mount+188:mov0x20(%rbx),%rax
0x81183940 vfs_kern_mount+192:add$0x70,%rdi
0x81183944 vfs_kern_mount+196:mov%rbx,0x10(%rbx)
0x81183948 vfs_kern_mount+200:mov%rax,0x18(%rbx)
0x8118394c vfs_kern_mount+204:callq 0x8109c1a0
up_write
0x81183951 vfs_kern_mount+209:xor%esi,%esi
0x81183953 vfs_kern_mount+211:mov%r15,%rdi
0x81183956 vfs_kern_mount+214:callq 0x8112c820
free_pages
*Thats the definition of function*
vfs_kern_mount(struct file_system_type *type, int flags, const char *name,
void *data)
{
struct vfsmount *mnt;
char *secdata = NULL;
int error;
if (!type)
return ERR_PTR(-ENODEV);
error = -ENOMEM;
* mnt = alloc_vfsmnt(name);*
if
Re: Getting struct page pointer from virtual address
More information : - Linux kernel version : 2.6.32 (But I would like a method which is portable to other higher versions as well) - I tried using follow_page, but this function is not exported from the kernel so, can't use it. (Any reason why this function is not exported??) Thanks Ajay From: ajay saini ajay_saini1...@yahoo.co.in To: kernelnewbies@kernelnewbies.org kernelnewbies@kernelnewbies.org Sent: Tuesday, 3 September 2013 1:21 PM Subject: Getting struct page pointer from virtual address Hey, I am working on a linux kernel module and I have a virtual address and mm (struct mm_struct) for a process in this module. I can find the virtaul memory area to which this address belongs to by using find_vma. Is there a function in the linux kernel which I can use in this module (i.e. exported from the kernel) to get struct page pointer for this virtual address. Thanks Ajay___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Dcache_lock replacement
Can you explain the code paths that are causing an issue with dcache_lock gone? I would try to explain whatever I can to the best of my ability but if further insight is needed, the code can be reffered at https://github.com/HeisSpiter/hepunion/. See I am working on a type of Union file System which has two branches - 1. Read Only- have individual mount point 2.Read Write-also have individual mount point Now they coexist in a merged mount point. so when such a mount command gets issued in my driver(HEPunion FS)- mount -t Hepunion -o /tmp/rw_path=RW:/tmp/ro_path=RO none /tmp/merged Here /tmp/rw-path is the Read Write branch mount point, /tmp/ro_path is the Read Only branch mount point and merged point of the two branches are /tmp/merged 1.In this mount command following three main steps happen for each branch one after the other Step1-hepunion_read_super which involves a)get_branches: MNT_POINT1=RW MNT_POINT2=RO b)make_path: RW, make_path: RO Step2-hepunion_permission which involves a) get_relative_path: b) get_file_attr: Step3- hepunion_getattr which involves a) get_relative_path: b) get_file_attr: So my mount is successful 2. But when I navigate to mount point and do a ls THE KERNEL CRASHES The last few messages I collect from crash utility is the call to hepunion_permission which again involves the above two steps- a) get_relative_path:-*This is where my kernel crashes * b) get_file_attr:- I do not reach here *Now what I fail to understand that when a previous call to hepunion_permission was successful in mount command why it now fails at ls . * P.S.- All the above discussed calls are based on the dmesg and the syslogs and may not be properly visualized by just looking at the driver code. If the the entire kernel log is needed for various steps, I can also provide that. On Tue, Sep 3, 2013 at 3:40 AM, valdis.kletni...@vt.edu wrote: Since lot of things have changed from 2.6.18 to 3.8 and I have taken a lot of care to replace the old kernel APIs with the newer ones but then too there have been certain things I haven't been able to replace and dcache_lock is one of them. Due to the absence of dcache_lock, I have not been able to properly lock stuff and writing/reading data that are being changed that maybe one of the reasons for instability. There's nothing stopping your driver from adding its own locking to protect itself from itself. If the problem is that you used to use dcache_lock to protect your critical variables from other parts of the kernel, you'll need to restructure your code to avoid the issue, or find other suitable locking. Can you explain the code paths that are causing an issue with dcache_lock gone? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Introducing Myself, Looking to Learn
Hi! I want to start working on the Linux kernel but am an absolute beginner. I am currently on my way through Robert Love's Linux Kernel Development and need help with finding something I can work on to get a hang of what it's like. I have also subscribed to the LKML, but find it completely incomprehensible! As a beginner, would it be better to work with the kernel of a specific OS (I'm running Ubuntu), or work on the upstream kernel? Thanks. Varad ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Introducing Myself, Looking to Learn
But please note that if you're finding it *completely* incomprehensible, you're probably not going to be able to make any real code contributions until you get up to speed. Hi Vladis! Thanks for replying. I think I would be fine with writing real code once I figure out what goes where. Is there something I should start with, which would help me bring myself at par? Thanks. Varad ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Introducing Myself, Looking to Learn
On Wed, 04 Sep 2013 02:05:42 +0530, Varad Gautam said: Hi Vladis! Thanks for replying. I think I would be fine with writing real code once I figure out what goes where. Well, assuming you have a background as a professional or very serious amateur programmer, *and* you have a *particular* drive to do something specific. There's still a lot of code being added by amateurs who have some weird USB device that doesn't have a driver and so on - but there's less and less room for beginners that just want to hack code and don't care where. Data structures and algorithms have gotten more complex, the locking is more fine-grained and subtle - gone are the days you could just take the Big Kernel Lock and not worry, now you ofteh have to understand stuff like RCU locking. So you might want to stop and ask yourself *why* you want to write code for the kernel. :) (Hint - we probably need more testers than we need more coders. Every single person that runs linux-next kernels and does QA and reports issues is a help) pgpCcqq9mF7Tj.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Introducing Myself, Looking to Learn
On Tue, 3 Sep 2013, valdis.kletni...@vt.edu wrote: On Wed, 04 Sep 2013 02:05:42 +0530, Varad Gautam said: Hi Vladis! Thanks for replying. I think I would be fine with writing real code once I figure out what goes where. Well, assuming you have a background as a professional or very serious amateur programmer, *and* you have a *particular* drive to do something specific. There's still a lot of code being added by amateurs who have some weird USB device that doesn't have a driver and so on - but there's less and less room for beginners that just want to hack code and don't care where. Data structures and algorithms have gotten more complex, the locking is more fine-grained and subtle - gone are the days you could just take the Big Kernel Lock and not worry, now you ofteh have to understand stuff like RCU locking. So you might want to stop and ask yourself *why* you want to write code for the kernel. :) i'm going to jump in here since i see this question annoyingly frequently -- i'm new to the kernel and i want to get involved and write code; how do i start? to be blunt, if that's your starting point, you're not ready to write code for the kernel. period. as vladis quite correctly points out, gone are the days when there was piles of simple coding to be done. most of the kernel is well established, solid and stable, and ongoing development is *very* advanced. in other words, there's less and less room for enthusiastic beginners. but there's more. at the very least, you should have an idea of what part of the kernel interests you most. if you can't even identify which major subsystem -- networking, USB, video, etc. -- you want to work on, you aren't even *remotely* ready to start writing code. it's somewhat absurd to say you want to get involved in kernel development, then ask *others* where you should start. it's like saying, i really want to write a book, but i have no idea what i should write about. can you give me some ideas for a plot? and characters? and possibly an ending? yes, it's that silly. if you're a beginner, then the obvious starting point is to start reading. and read. and read. and when you're done reading, read some more. and slowly, you'll figure out what interests you most. and that's where you then spend your time. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Being a newbie ;-) (was Re: Introducing Myself, Looking to Learn)
On Sep 03 2013, Robert P. J. Day wrote: i'm going to jump in here since i see this question annoyingly frequently -- i'm new to the kernel and i want to get involved and write code; how do i start? to be blunt, if that's your starting point, you're not ready to write code for the kernel. period. It seems to me there are a lot of reasons to ask this question, and it's not a great idea for the kernel (in the long run) to discourage newbies to the extent that new blood never comes in. as vladis quite correctly points out, gone are the days when there was piles of simple coding to be done. most of the kernel is well established, solid and stable, and ongoing development is *very* advanced. in other words, there's less and less room for enthusiastic beginners. but there's more. I think you can expect it will be a while before you write anything that's remotely worth upstreaming, except possibly drivers for obscure hardware or possibly minor bug fixes, for bug(s) that happen to replicate on your own system. That doesn't mean you can't learn. In fact, it's even possible to get paid to learn. At the moment, I'm working in a shop that ships appliances that include linux. My job is to investigate whatever goes squirrely at the kernel level, and make the system play nicely with our latest hardware. Since we're running an older version of linux, the most common result of these investigations is to find and merge an upstream patch. Another common result is to find a bug in one of our own kernel modules. Next most likely is a configuration issue. If none of these apply, we get to write the patch ourselves. If the problem affects recent kernels, we'll also submit it to LKML etc. I haven't personally had cause to submit anything yet. it's somewhat absurd to say you want to get involved in kernel development, then ask *others* where you should start. it's like saying, i really want to write a book, but i have no idea what i should write about. can you give me some ideas for a plot? and characters? and possibly an ending? yes, it's that silly. I tend to take this as a request for suggestions for learning exercises, or even simply where to start learning. It's a big and complex system, with layers and layers of details to deal with. I doubt where do I start is really a variant of what should I develop? (The right answer to that is pretty simple - whatever you want to have available, that isn't available ;-)) if you're a beginner, then the obvious starting point is to start reading. and read. and read. and when you're done reading, read some more. and slowly, you'll figure out what interests you most. and that's where you then spend your time. Personally, I'd suggest playing with the code. Don't expect to produce something upstreamable. My latest ludicrous activity was reinventing part of ftrace ;-) I didn't mean to do that, I was just trying to get a record of [..things ftrace could have gotten me..] on a repeatedly failing system. Net result - I learnt more than I would have if I'd just used ftrace, and my coworkers are being patient about the time it's taking me to solve the original crash. (Fortunately I found a problem with the kernel configuration we were using for that appliance, as a side effect of my experiments, so the effort wasn't completely wasted ;-) And now I know about ftrace, and have ideas about extending it to do the next batch of things I want.) rday -- Arlie (Arlie Stephens ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Introducing Myself, Looking to Learn
On Tue, Sep 3, 2013 at 4:29 PM, Varad Gautam varadgau...@live.com wrote: Hi! I want to start working on the Linux kernel but am an absolute beginner. I am currently on my way through Robert Love's Linux Kernel Development and need help with finding something I can work on to get a hang of what it's like. I have also subscribed to the LKML, but find it completely incomprehensible! As a beginner, would it be better to work with the kernel of a specific OS (I'm running Ubuntu), or work on the upstream kernel? Hi, If you are an absolute beginner, I recommend you to start studying and hacking a small O.S., like the xv6: http://pdos.csail.mit.edu/6.828/2012/xv6.html http://pdos.csail.mit.edu/6.828/2012/xv6/book-rev7.pdf If you need a background on the low level, I suggest you to read this: http://download.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf -- Augusto Mecking Caringi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Being a newbie ; -) (was Re: Introducing Myself, Looking to Learn)
I wouldn't recommend playing with the code to ubuntu users that barely know what a terminal is. For absolute beginners and novice enthusiasts I usually recommend to start by installing Gentoo following its handbook. The Gentoo handbook is a very good learning source for beginners and it guides you through a bit of everything. And because you have to configure most of the system and compile (almost) everything from scratch, you start to get a feeling of the system as a whole. This should take a few weeks for absolute beginners. If they survive the Gentoo battle, then the dumb drivers from LDD are good next steps, because now the hacker enthusiast have some experience with (re-)compiling the kernel and with using the command line to figure out how to find causes of his problems. On Tue, Sep 3, 2013 at 5:37 PM, Arlie Stephens ar...@worldash.org wrote: On Sep 03 2013, Robert P. J. Day wrote: i'm going to jump in here since i see this question annoyingly frequently -- i'm new to the kernel and i want to get involved and write code; how do i start? to be blunt, if that's your starting point, you're not ready to write code for the kernel. period. It seems to me there are a lot of reasons to ask this question, and it's not a great idea for the kernel (in the long run) to discourage newbies to the extent that new blood never comes in. as vladis quite correctly points out, gone are the days when there was piles of simple coding to be done. most of the kernel is well established, solid and stable, and ongoing development is *very* advanced. in other words, there's less and less room for enthusiastic beginners. but there's more. I think you can expect it will be a while before you write anything that's remotely worth upstreaming, except possibly drivers for obscure hardware or possibly minor bug fixes, for bug(s) that happen to replicate on your own system. That doesn't mean you can't learn. In fact, it's even possible to get paid to learn. At the moment, I'm working in a shop that ships appliances that include linux. My job is to investigate whatever goes squirrely at the kernel level, and make the system play nicely with our latest hardware. Since we're running an older version of linux, the most common result of these investigations is to find and merge an upstream patch. Another common result is to find a bug in one of our own kernel modules. Next most likely is a configuration issue. If none of these apply, we get to write the patch ourselves. If the problem affects recent kernels, we'll also submit it to LKML etc. I haven't personally had cause to submit anything yet. it's somewhat absurd to say you want to get involved in kernel development, then ask *others* where you should start. it's like saying, i really want to write a book, but i have no idea what i should write about. can you give me some ideas for a plot? and characters? and possibly an ending? yes, it's that silly. I tend to take this as a request for suggestions for learning exercises, or even simply where to start learning. It's a big and complex system, with layers and layers of details to deal with. I doubt where do I start is really a variant of what should I develop? (The right answer to that is pretty simple - whatever you want to have available, that isn't available ;-)) if you're a beginner, then the obvious starting point is to start reading. and read. and read. and when you're done reading, read some more. and slowly, you'll figure out what interests you most. and that's where you then spend your time. Personally, I'd suggest playing with the code. Don't expect to produce something upstreamable. My latest ludicrous activity was reinventing part of ftrace ;-) I didn't mean to do that, I was just trying to get a record of [..things ftrace could have gotten me..] on a repeatedly failing system. Net result - I learnt more than I would have if I'd just used ftrace, and my coworkers are being patient about the time it's taking me to solve the original crash. (Fortunately I found a problem with the kernel configuration we were using for that appliance, as a side effect of my experiments, so the effort wasn't completely wasted ;-) And now I know about ftrace, and have ideas about extending it to do the next batch of things I want.) rday -- Arlie (Arlie Stephens ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Henrique Rodrigues http://www.dcc.ufmg.br/~hsr ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Introducing Myself, Looking to Learn
Hi Varad, On Sep 04 2013, Varad Gautam wrote: Hi! I want to start working on the Linux kernel but am an absolute beginner. I am currently on my way through Robert Love's Linux Kernel Development and need help with finding something I can work on to get a hang of what it's like. How much of a beginner are you? In particular, how much do you know about operating system kernels in general? And how much multi-threaded programming have you done, in situations where you have to manage your own locking? If you don't have good practical understanding of concurrency, you might want to do yourself a favour and do some work with a large multi-threaded program until you've got practical experience with race conditions, lock contention, and deadlocks. Linux is a fairly mature monster. This means that the simple outlines of what all OSes do tend to be obscured by layers of complexity. That's one some folks use BSD for their OS-kernel classes. You'll be doing more digging in linux. Will you be comfortable with that? I have also subscribed to the LKML, but find it completely incomprehensible! My question would be incomprehensible how? There's a lot of shared context, which you won't have, and diffs aren't the best way to learn what's in a piece of code. That level of incomprehensible makes sense to me. Beyond that, there's learning you need to do. As a beginner, would it be better to work with the kernel of a specific OS (I'm running Ubuntu), or work on the upstream kernel? Pick one that you actually run - that way you're set up to try out the results of your experiments, and more likely to encounter some problem that motivates you to attack it. Personally I'd prefer not to be testing on my development system [hate it when that's unstable], but if you aren't playing with hardware, VMs make great test environments. Beyond that, my advice would be to do something trivial. How about a kernel module that prints Hello world? It's useless, but you'll start internalizing the build system. Then do something else trivial, that let's you poke the kernel somewhere else. Eventually either it'll start making sense, and your ambitions will increase - or you'll decide you aren't having fun and try somethign else. -- Arlie (Arlie Stephens ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Introducing Myself, Looking to Learn
I would suggest you to fix on a module and start following what are the bugs in it and see if you can fix it or try understand what others fix. From: Arlie Stephens Sent: 4/9/2013 7:08 To: Varad Gautam Cc: kernelnewbies@kernelnewbies.org Subject: Re: Introducing Myself, Looking to Learn Hi Varad, On Sep 04 2013, Varad Gautam wrote: Hi! I want to start working on the Linux kernel but am an absolute beginner. I am currently on my way through Robert Love's Linux Kernel Development and need help with finding something I can work on to get a hang of what it's like. How much of a beginner are you? In particular, how much do you know about operating system kernels in general? And how much multi-threaded programming have you done, in situations where you have to manage your own locking? If you don't have good practical understanding of concurrency, you might want to do yourself a favour and do some work with a large multi-threaded program until you've got practical experience with race conditions, lock contention, and deadlocks. Linux is a fairly mature monster. This means that the simple outlines of what all OSes do tend to be obscured by layers of complexity. That's one some folks use BSD for their OS-kernel classes. You'll be doing more digging in linux. Will you be comfortable with that? I have also subscribed to the LKML, but find it completely incomprehensible! My question would be incomprehensible how? There's a lot of shared context, which you won't have, and diffs aren't the best way to learn what's in a piece of code. That level of incomprehensible makes sense to me. Beyond that, there's learning you need to do. As a beginner, would it be better to work with the kernel of a specific OS (I'm running Ubuntu), or work on the upstream kernel? Pick one that you actually run - that way you're set up to try out the results of your experiments, and more likely to encounter some problem that motivates you to attack it. Personally I'd prefer not to be testing on my development system [hate it when that's unstable], but if you aren't playing with hardware, VMs make great test environments. Beyond that, my advice would be to do something trivial. How about a kernel module that prints Hello world? It's useless, but you'll start internalizing the build system. Then do something else trivial, that let's you poke the kernel somewhere else. Eventually either it'll start making sense, and your ambitions will increase - or you'll decide you aren't having fun and try somethign else. -- Arlie (Arlie Stephens ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
