[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.x to 2.4.x



Hi

I know that Linux is not my experty, so maybe my question is silly.

>From software engineering point of view creating non official kernel version
==> whenever the kernel updated you loose your work. So it seems as the
wrong method.
Don't it be better to write a TCP/IP demon/driver and by this be (almost)
independent at the kernel version

Shahar
----- Original Message -----
From: "Shlomi Fish" <shlomif@techst02.technion.ac.il>
To: "guy keren" <choo@actcom.co.il>
Cc: <linux-il@linux.org.il>
Sent: Thursday, July 19, 2001 5:14 AM
Subject: Re: Porting and Extending a TCP/IP noise simulator from kernel
2.2.x to 2.4.x


> On Thu, 19 Jul 2001, guy keren wrote:
>
> >
> > forgive me for this anti-enthusiastic message, but you can implement
your
> > noise simulator without writing a single line of kernel source - you can
> > grab traffic using firewalling rules from kernel mode out into user
mode,
> > and there u can decide whether to let a packet go on, drop it, send it
> > with an error inside, and anything else that a C program allows you to
do.
> >
> > and it'll be able to sustain an ammount of trafic good enough for your
> > needs, i imagine. the question, however, is whether such an approach
> > doesn't defeat the purpose of the lab.
> >
>
> The project is defined to be in the kernel. Otherwise, I think it won't
> be able to scale too much. But maybe we can use the firewalling framework
> in order to better simulate the noise. Hmmm....
>
> > > 1. Is the Networking and TCP/IP stack of kernel 2.4.x very different
> > > internally from that of kernel 2.2.x? From what I understood it was
> > > modified to support multi-threaded processes, but I'm more interested
to
> > > know if thecode remained pretty much the same.
> >
> > some parts were completely rewritten (e.g. the firewalling code). i
think
> > most changes that got to do with what u call 'multi-threaded processes'
is
> > actually not related to threads specifically - but to paralel execution
in
> > general - and got to do with having mroe fine-grained usage of locks
> > inside the kernel, to allow taking better advantage of existance of
> > seveval CPUs in SMP mode.
> >
>
> No, the problem was that in kernel 2.2.x the TCP/IP stack was not
> multi-threaded. That is a blocking accept() call would have blocked the
> entire process, and if one thread sent data the other would get stuck,
> etc. etc.
>
> AlexSh can testify on a case where it became apparent.
>
> > >2. What I thought was to implement some of the noise logic as a patch
to
> > > the kernel, while implementing the arbitrator of it as a separate
module.
> > > During the previous project, the whole thing was implemented as apatch
> > > and they had to reboot constantly.
> > >
> > > My question is: can the logic that decides whether to drop, ruin, or
how
> > > much time to delay a packet, can be implemented as a separate module
that
> > > will communicate with the main kernel somehow?
> >
> > yes. you could write your own 'firewall' module, and plug it into the
> > kernel. the internel API in kernel 2.4 supports plugging of several API
> > modules, chained on-top of each other. this way, you don't need to
modify
> > the kernel's code at all, and write everything as a module.
> >
>
> If you say so - it might save us a lot of work and we may not need to use
> the original code at all (except as a refernce).
>
> > > 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.
> >
>
> Yes, but kernel debuggers enable me to see the value of my variables. (!)
> and they are interactive and I can do more at that point than just reboot
> a safe kernel and look at my source code. At least that's how it is in
> Soft-ICE, which Personal ICE aims to resemble.
>
> > > 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.
> >
>
> Sounds good. If you can, please put the sys-call tracker source on the web
> so my partner and my project's supervisor will be able to look at it.
>
> I think gdb still beats Personal ICE hands-on, but the kernel debuggers
> will probably prove to be useful too.
>
> > > 5. Simulating network noise may be of interst to Comp. Net.
researchers
> > > and Net-Admins world-wide. For instance: can MOSIX or Beowulf work
with
> > > this patch installed on one or more of the clusers' computers? I'd
like to
> > > find out.
> > >
> > > 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.
> > >
> > > Now, Linus objected to the MOSIX code be integrated into the kernel
that
> > > way, so I don't know if he'll accept such patch. I guess I'll have to
ask
> > > him. Of course, the patch can be maintained vis-a-vis with the kernel
> > > source (like MOSIX), but it would be a better idea if it is in the
Linus'
> > > source tree.
> >
> > since it can be done in user mode, or as a kernel module without
modifying
> > any line of code in the kernel, there's no point in integrating this
into
> > the kernel's sources.
> >
>
> If we indeed end up with a user-level/kernel module arbitrator, then we
> can indeed distribute and maintain it separately from the kernel. However,
> if many researchers and Internet workers find it useful, Linus may decide
> to include it there.
>
> > > 6.
> > > 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 :)
> >
>
> I could put it in a separate directory. Put the messages of every week (or
> every day?) in a separate mailbox, and maybe get a separate account.
>
> > > There are various web resources that summarize the activity there. I
read
> > > the Linux Weekly News' kernel section, but it's a relatively short
> > > summary. It recommends other resources such as "Kernel Traffic", but
do
> > > they beat reading the actual mailing list? Also, are there are other
> > > mailing lists of significance for kernel developers?
> >
> > they are readable - they work as commentary to the actual threads, and
its
> > quicqer to read. if a specific thread interests you more - go into it.
> >
>
> Cool. That sounds useful.
>
> > 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.
> >
>
> My supervisor recommended "The Linux Kernel Internals", but we
> probably could get him to purchase another book. Well, STFEing is the key
> to success.
>
> Regards,
>
> Shlomi Fish
>
> > --
> > guy
> >
> > "For world domination - press 1,
> >  or dial 0, and please hold, for the creator." -- nob o. dy
> >
>
>
>
> ----------------------------------------------------------------------
> 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
>
>


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