[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Porting and Extending a TCP/IP noise simulator from kernel 2.2.xto 2.4.x
- To: mulix <mulix(at-nospam)actcom.co.il>
- Subject: Re: Porting and Extending a TCP/IP noise simulator from kernel 2.2.xto 2.4.x
- From: Shlomi Fish <shlomif(at-nospam)techst02.technion.ac.il>
- Date: Fri, 20 Jul 2001 13:43:43 +0300 (EEST)
- Cc: guy keren <choo(at-nospam)actcom.co.il>, <linux-il(at-nospam)linux.org.il>
- Delivered-To: linux.org.il-linux-il@linux.org.il
- In-Reply-To: <Pine.LNX.4.33.0107191728030.7086-100000@alhambra.merseine.nu>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
On Thu, 19 Jul 2001, mulix wrote:
> On Thu, 19 Jul 2001, guy keren wrote:
>
> > > 3. I'd like to use kernel debuggers like SGI's kdb and Personal ICE
> > > (http://pice.sourceforge.net/) to aid in analysing errors. I know they are
> > > not distributed with the kernel of Linus, but I suppose they can be
> > > applied quite easily.
> > >
> > > Assuming the main kernel (which has both or one of the debuggers compiled
> > > into it) has an OOPS fault, will they allow me to diagnose it?
> >
> > you don't need a debugger in order to get an OOPS message diagnosed. klogd
> > does that for you, if you maintain an up-to-date symbol map. it'll
> > translate the stack into kernel symbols offsets, and you could locate the
> > relevant instruction by dissassembling your module.
>
> if i recall correctly, klogd oops handling is deprecated, and you should
> use ksymoops instead.
>
> anyway, there's no need to worry about oopses yet. there's a very nifty
> project called UML (User Mode Linux), which an implementation of a
> kernel running as a user land process. one of the main advantages is of
> course, the ability to code for the kernel and debug in user space, just
> like you would debug any other c program.
>
Excellent!
I completely forgot about that. Of course I know about it, but it did not
come to my mind, so thanks for reminding me. But how good it is in
simulating an entire network or connecting to a real network. And it is
probably slower than the real kernel.
I'll probably take Guy's approach of writing it a separate user-level
process and then converting it to a kernel module.
> more information is available at: http://user-mode-linux.sourceforge.net
>
> > > 4. Naturally, to test the module, I'll need to simulate network activity. I
> > > can do that with actual packets that arrive from different machine (or
> > > from two different Ethernet cards on the same computer - %-)) but I could
> > > also build an internal virtual network, and do some manipulations there.
> > >
> > > Or could I? I think depending on packets that arrive from the hardware at
> > > the early stages of the project is a bad idea<tm>, because kernel
> > > programming is bad enough without messing with the hardware. Naturally, we
> > > will make sure it works with various hardware, but can we postpone it to
> > > later stages? Should we do that?
> >
> > you could write your code so that you could compile it both in user mode
> > and in kernel mode. then you could write the logics in user mode and test
> > it there, and only when its debugged - put it in the kernel. i could send
> > you the syscall tracker module's sources as an example of one way this
> > could be done.
>
> or you could use UML (see above). it supports networking using "virtual"
> interfaces and network drivers.
>
> > > So, what do you recommend regarding the issue of whether or not it should
> > > be integrated into the main kernel? I think the patch to the kernel should
> > > be #ifdef'd because delaying, ruining, or dropping packets deliberately is
> > > something most people don't want to enable.
>
> i think this is a question that should be ask on linux-kernel.
> personally, i highly doubt this kind of patch would ever be integrated
> (let me know in private if you want to know why).
>
Please send me a reply in private.
> > > Do you recommend joining or monitoring the linux-kernel mailing list. I
> > > know the amount of daily messages there is very big, much more than all
> > > the other mailing-list I am a member of. I could request a bigger quota to
> > > accomodate for it, but I'll probably press the "D" button maniacly.
> >
> > i think i see muli waving his hand enthusiastically with a 'yes' vote :)
>
> yup. small hint, though:
>
> :0:
> * ^Sender: linux-kernel-owner@vger.kernel.org
> linux-kernel
>
What does this procmail filter do? I always use "^TO" rather than
"^Sender".
> :)
>
> > but its more likely that for such a specifically targeted project, reading
> > archives of such maling lists, and googling, and reading the kernel's
> > source code, and purchasing a copy of alessandro rubini's "linux device
> > drivers" book to learn how the kernel internally works - would be more
> > productive.
>
> i have the book here, if you'd like to peruse it. a new version should
> be coming out, and i think i heard it will also be available in its
> entirety on the web.
>
Hopefully it will, because it would be easier to browse and search it that
way. And it will be free :-). But if you can lend me the book, I thank you
in advance. Can you bring it to the R2L meeting?
> all in all, cool project, shlomi. in what class is it?
In EE we have to perform two semesterial projects (or one yearly one). The
lab that hosts the project is the EE Department's Computer Networks Lab.
Check:
http://comnet.technion.ac.il/
for details.
Thanks for your commentary,
Shlomi Fish
> --
> mulix
> http://www.advogato.com/person/mulix
>
> linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
>
>
----------------------------------------------------------------------
Shlomi Fish shlomif@t2.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
A more experienced programmer does not make less bugs. He just realizes
what went wrong more quickly.
=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il