[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




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.

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

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

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

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

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

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

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

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.

--
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy


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