Linux-Development-Sys Digest #254, Volume #8 Fri, 3 Nov 00 07:13:11 EST
Contents:
Re: Linux GUI development (Christopher Browne)
Re: Linux in assembly (Christopher Browne)
Re: Linux API (Christopher Browne)
connection migration ??? (William Huang)
IP Masquerade Modules ("Daniel Lenski")
Re: Linux in assembly (Tim Roberts)
struct resource (David Alexander)
Driver for ATM Interphase 5515 Adapter ("U. Siegel")
Re: Disk Replication (bootable) (Peter Pointner)
Re: Linux GUI development (Maciej Golebiewski)
changing source ip address ("ByungDeok Kim")
Re: connection migration ??? (kim dk)
Re: changing source ip address (Stefaan A Eeckels)
Re: Disk Replication (bootable) (Kasper Dupont)
Re: Linux GUI development (Kasper Dupont)
Re: Accessing files from within a kernel module (Kasper Dupont)
Re: Linux in assembly (Kasper Dupont)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Linux GUI development
Reply-To: [EMAIL PROTECTED]
Date: Fri, 03 Nov 2000 02:35:52 GMT
In our last episode (Thu, 02 Nov 2000 16:42:28 GMT),
the artist formerly known as [EMAIL PROTECTED] said:
>When technology is taken a look at from a broad viewpoint
>and from a historical perspective, there are patterns
>that must be recognized as having survival characteristics.
Blah, blah, blah...
And this has exactly what to do with development of the Linux kernel?
--
Rules of the Evil Overlord #127. "Prison guards will have their own
cantina featuring a wide variety of tasty treats that will deliver
snacks to the guards while on duty. The guards will also be informed
that accepting food or drink from any other source will result in
execution." <http://www.eviloverlord.com/>
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Linux in assembly
Reply-To: [EMAIL PROTECTED]
Date: Fri, 03 Nov 2000 02:36:10 GMT
In our last episode (Thu, 02 Nov 2000 16:47:46 GMT),
the artist formerly known as [EMAIL PROTECTED] said:
>could it be possible to move some of the linux kernel c stuff into
>assembly ported and fine tuned to each processor so that it
>is fast and efficient? There are technology in this area
>using machine language modules that can be loaded and swapped in
>so that they could be developed in a modular way (like how
>software components like classes in C++ and java work). I believe
>something along the lines of V2_OS but retain the multitasking
>and other virtual memory stuff.
>
>This would speed up the core cycles.
>
>Of course, the other direction that the industry is also following
>is to wait for the microprocessor to catch up to speed. Like
>java, or create a microprocessor that can run native cross cpu
>programs natively (like picojava chips).
Sometimes randomly selected .signatures are chosen with great
serendipity...
Do you have any _specific_ performance bottleneck in mind? Or are you
merely committing the computing sin of blathering on about efficiency in
the absence of having any application for it?
Jon Bentley has commented on how a team spent time rewriting a heavily
executed portion of an operating system using _microcode_, only to find
that they were optimizing the idle loop and thereby _utterly wasting
their time._ Doing _nothing_ faster is not an improvement.
--
"More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity." -- W.A. Wulf
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Linux API
Reply-To: [EMAIL PROTECTED]
Date: Fri, 03 Nov 2000 02:41:51 GMT
In our last episode (Sun, 29 Oct 2000 23:24:44 -0000),
the artist formerly known as [EMAIL PROTECTED] said:
>On Sat, 21 Oct 2000 13:57:45 -0700 Jim Fischer <[EMAIL PROTECTED]> wrote:
>|> Hello there
>|> Is the any documentation on Linux API just
>|> like the M$ win API?
>|
>| The Linux source code *is* the Linux API. <g>
>As soon as we drop the notion that one has to read massive amounts of
>uncommented or poorly commented code in order to understand how to
>make use of the code (modifying it is a different issue) then many
>more open source projects will become more useful to more people.
>I'm glad you put the "<g>" on there. Too many people don't. And
>that tells me there is no design (or reason) to what many people do
>when they code.
The <g> should get squared, because The Way To Go is _NOT_ to use the
Linux source code as "the Linux API."
The Right Thing is to use the documented functions found in GLIBC.
They tend to follow De Jure standards, and are less likely to
massively change when:
a) ACLs are let in, and significantly affect the behaviours of
permissions;
b) Capabilities head in [ditto];
c) Preferred Default Behaviour becomes to use 64 bit file descriptor
values ala LFS.
These and other such things should be left independent of the kernel;
you shouldn't go directly at the kernel unless you actually _need_ to,
and if that be the case, then reading _and understanding_ the "massive
amounts of code" starts to be necessary.
>| Actually, there are some books available on the Linux kernel, but
>| the kernel sources change so frequently that some of the content in
>| these books is obsolete before the books are even published. IOW,
>| you'll probably never walk into a Barns & Nobels bookstore and find
>| a book that discusses the APIs of "recent" Linux kernels (e.g., the
>| 2.4 kernels).
>I don't know about Barnes & Noble, but I found one in Border's that
>talked about the design of 2.4. I didn't buy it because I don't need
>it (yet).
... If you're not writing your own utilities to talk directly with
/proc, aren't writing your own filesystems, and aren't doing stuff of
equivalent "kernel intimacy," then you probably won't need it any time
soon.
Five years from now, you might be running those programs that use
GLIBC on your 2000 MIPS 1GB AMD Sledgehammer running Hurd... :-)
--
(concatenate 'string "cbbrowne" "@" "hex.net")
<http://www.ntlug.org/~cbbrowne/lsf.html>
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." -- Andrew Tanenbaum, 1992.
------------------------------
From: William Huang <[EMAIL PROTECTED]>
Subject: connection migration ???
Date: 3 Nov 2000 04:45:42 GMT
Does someone haert aboout connection migration or socket migration ? It means
that when a TCP connection established between client and server A, and then server A
migrate the connection to server B, such as layer 7 switch to handle with load
balancing.
Most important of all, does someone know how to implement the connection
migration in detail technically ?
------------------------------
From: "Daniel Lenski" <[EMAIL PROTECTED]>
Subject: IP Masquerade Modules
Date: Fri, 03 Nov 2000 00:22:48 +0500
Hi, I'm trying to learn to write IP masquerading modules for the 2.2
kernels. I have this module that registers itself on port 913/TCP, and I
function which is supposed to catch all the incoming packets on that port
and hex dump them to the kernel log. However, it seems as if the
incoming packet receiver is never called.
My ip_masq_app structure looks like this:
/***********************************************************************/
struct ip_masq_app ip_masq_sidecar = {
NULL, /* next */
"sidecar", /* name */
0, /* type */
0, /* n_attach */
masq_sidecar_init, /* ip_masq_init_1 */
masq_sidecar_done, /* ip_masq_done_1 */
masq_sidecar_out, /* pkt_out */
masq_sidecar_in, /* pkt_in */
};
/***********************************************************************/
And then I register it with:
/***********************************************************************/
int
masq_sidecar_init()
{
int status;
printk(KERN_INFO "masq_sidecar_init: entering ...\n");
masq_incarnation = kmalloc(sizeof(struct ip_masq_app), GFP_KERNEL);
if (masq_incarnation == NULL) return -ENOMEM;
memcpy(masq_incarnation, &ip_masq_sidecar, sizeof(struct ip_masq_app));
status = register_ip_masq_app(masq_incarnation, IPPROTO_TCP, port);
if (!status)
printk(KERN_INFO "ip_masq_sidecar_init: loaded support on port %d\n",
port);
printk(KERN_INFO "masq_sidecar_init: exiting ...\n");
return status;
}
/***********************************************************************/
So then I start up a little server on port 913 that just hexdumps
everything that comes to it. But the incoming packet handler in the
kernel module never seems to get
called. The packets pass through to the hexdumper, however. Do I need
to load the kernel module before starting ipchains or something?
Shouldn't I be able to load it at any time?
Thanks for your advice!
--
Daniel Lenski
[EMAIL PROTECTED]
"If we couldn't laugh at things that didn't make sense,
we couldn't react to a lot of the world around us."
--Calvin and Hobbes
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: Linux in assembly
Date: Thu, 02 Nov 2000 22:47:05 -0800
[EMAIL PROTECTED] (Christopher Browne) wrote:
>
>Jon Bentley has commented on how a team spent time rewriting a heavily
>executed portion of an operating system using _microcode_, only to find
>that they were optimizing the idle loop and thereby _utterly wasting
>their time._ Doing _nothing_ faster is not an improvement.
Yep. This is a derivation of Amdahl's Law, first expressed by Gene Amdahl
in the 1970's when vector processing mainframes were becoming the rage.
His law stated that optimization of any part of an algorithm cannot improve
the performance the overall algorithm more than the portion which was not
accelerated.
Thus, if a routine uses 10% of your CPU time, even if you reduce its CPU
time to zero, you cannot improve overall performance more than 10%.
This applies to the Linux kernel; any routine which used a measurable
percentage of overall execution time has long since been tweaked into
assembler.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: David Alexander <[EMAIL PROTECTED]>
Subject: struct resource
Date: Fri, 03 Nov 2000 07:18:30 GMT
Where can I get information in the linux resource structure? In
particular I am interested from a PCI perspective - when I call
allocate_resource from my architecture specific PCI initialization code
what exactly am I doing?
Thanx,
Dave
------------------------------
From: "U. Siegel" <[EMAIL PROTECTED]>
Subject: Driver for ATM Interphase 5515 Adapter
Date: Fri, 03 Nov 2000 09:38:28 +0100
Hi folks,
anybody out there developing a driver for the ATM Interphase 5515
Adapter?
If not, anybody, who can give assistance in developing such a driver?
Thanks in advance!!
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: Disk Replication (bootable)
Date: 3 Nov 2000 07:24:43 +0100
Tom J <[EMAIL PROTECTED]> wrote:
> Hi.
> This is what I've been trying.
[snip]
> *4. cpio --pass-through /mnt/hd2 < files.txt
> The files.txt has everything in it except proc/*, dev/* and /mnt/hd2/ .
> It turns out since the drive has only 512 cylinders I don't have to have a
> boot partition, but anyway.
> 5. I am trying to make device nodes with MAKEDEV by
> cp /dev/MAKEDEV /mnt/hd2/dev/
> cd /mnt/hd2/dev/ ; ./MAKEDEV
> but this doesn't work. I was assuming that I can't just copy device
> nodes. Maybe I can.
I am not sure about cpio, but cp copies device files if you use -a. So you
could just do: cp -ax / /mnt/hd2
> 6. So what if I edit /etc/lilo.conf
> to add
> image=/mnt/hd2/vmlinuz
> label=linux
> read-only
> root=/mnt/hd2/dev/hda3
> I mean, then the boot block will point to the wrong disk drives.
> I want to be able to move the new disk drive to IDE primary master.
> How can I install a boot block on a drive mounted at /mnt/hd2 that
> it should boot from /vmlinuz?
You could use "lilo -r /mnt/hd2" to tell lilo to chroot to your target
first. And you must tell it about your disk setup:
boot=/dev/hdb # or hdb1 or whereever it should write it
disk=/dev/hdb
bios=0x80 # tell lilo that your current hdb will be
# the first disk when actually booting
image=/vmlinuz # its chroot'ed, so it uses the target.
# but didn't you have a boot partition?
root=/dev/hda3
Peter
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: Re: Linux GUI development
Date: Fri, 03 Nov 2000 09:53:09 +0100
[EMAIL PROTECTED] wrote:
> Graphical User Interface (GUI). The keyboard has been through
> many evolutions and have settled on QWERTY layout for latin
> characters. There is not much that can be changed there except
> addition of more buttons. However, there is a tradeoff in
I'd love to see your face when you're shown a French-layout
keyboard :)
> A different technology derived from the military is the
> mouse (and joystick). These allow previously difficult
I hope you have informed Doug Engelbart (spelling?) about this
breaking news?
> What needs to happen in the linux internet space is to initiate
> different GUI incarnations and the development of them in internet
> time. An explosion of applications and GUI interface needs to
At least you're an expert in buzzwords.
Maciej
------------------------------
From: "ByungDeok Kim" <[EMAIL PROTECTED]>
Subject: changing source ip address
Date: Thu, 2 Nov 2000 18:01:48 +0900
Hi,
Does anybody know how to change source ip address using socket?
for example, if my address is 43.4.23.1 then, When I send data using socket,
then the ip source address is always 43.4.23.1.
is it possible to change it into 0.0.0.0 or any different ip address?
I tried to using SOCK_RAW and IPPROTO_RAW options when I make socket,
but It is only possible to change destination address.
thanks for reading,
------------------------------
From: kim dk <[EMAIL PROTECTED]>
Subject: Re: connection migration ???
Date: Fri, 03 Nov 2000 09:21:57 GMT
There is a experimental implementation.
http://www.chem.ucla.edu/~beichuan/etcp/
William Huang wrote:
> Does someone haert aboout connection migration or socket migration ? It
>means that when a TCP connection established between client and server A, and then
>server A migrate the connection to server B, such as layer 7 switch to handle with
>load balancing.
>
> Most important of all, does someone know how to implement the connection
>migration in detail technically ?
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: changing source ip address
Date: Fri, 3 Nov 2000 11:17:44 +0100
In article <[EMAIL PROTECTED]>,
"ByungDeok Kim" <[EMAIL PROTECTED]> writes:
>
> Does anybody know how to change source ip address using socket?
> for example, if my address is 43.4.23.1 then, When I send data using socket,
> then the ip source address is always 43.4.23.1.
Sounds logical, doesn't it?
> is it possible to change it into 0.0.0.0 or any different ip address?
Anything is possible, witness masquerading, and IP spoofing.
If you change the source address in a packet, then obviously
the reply will go to that address, not the originating system.
This might be what you want (if you're trying to break into
someone's network, or want to swamp their routers/firewall/
whatever), or alltogether unexpected ;-)
>
> I tried to using SOCK_RAW and IPPROTO_RAW options when I make socket,
> but It is only possible to change destination address.
It's not _that_ easy.
>
> thanks for reading,
You're welcome.
>
--
Stefaan
--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Disk Replication (bootable)
Date: Fri, 03 Nov 2000 11:53:25 +0100
Tom J wrote:
>
[...]
>
> I don't feel confident about using dd because how can the inodes from one
> drive be right for a different geometry drive?
The gemoetry is not a problem, but the size of the
partitions must match. It will probably work even
if the destination partition is larger, but you
will then vaste the rest of the destination partition.
If you will accept to vaste one cylinder pr. partition
you can probably do it that way.
> How can the boot information be right?
It will probably not be right at first, but it can
be fixed. You can create a temporary lilo.conf and
run lilo. The copied lilo.conf probably will work,
but first when the new system is booted, so another
solution would be to use a boot floppy the first
time the new system is booted, and then run lilo.
> Should we just plan to copy identical geometry drives? I don't think that we
> can do that in our situation of rehabilitating old dos equipment into linux
> systems.
That would be the easiest, but not the only possible
solution.
>
> Thanks very much for you help so far!
>
> --
> Tom J.; tej at world.std.com Massachusetts USA; MSCS; Systems Programmer
> Dist. Real-Time Data Acquisition S/W for Science and Eng. under POSIX,
> C, C++, X, Motif, Graphics, Audio http://world.std.com/~tej
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Linux GUI development
Date: Fri, 03 Nov 2000 12:12:19 +0100
[EMAIL PROTECTED] wrote:
>
[...]
>
> What is stopping the LINUX from mass adoption is the requirement
> for complex work on the human to set it up, and the sometimes
> troublesome sequences required for adding and deleting applications.
Installation and uninstallation of applications is not part
of the OS, you build applications on top of the OS that can
do this work. There exist different applications for Linux
that can do this. Many distributions now use rpm or something
simmilair using that is as simple as it can posibly be. If
you use Windows reinstalling the OS might be the only way to
uninstall a particular application.
[...]
>
> A lot of diehard unix/linux users insists it is great and
> a shell is indication of knowledge and power. This may be true,
> but the majority of the people in the world do not have time
> nor the interest in learning complex and archaic commands
> just to do simple stuff. This is why Microsoft is succeding
> right now, because they are becoming more and more userfriendly.
> Apple had a lock on the initial userfriendliness but was somehow
> knocked off of its pedastal. They are slowly coming back.
Unix/Linux have proven that GUI and commandline can coexist.
You don't need to use the commandline to do simple stuff, but
if you now how to use the commandline it is probably the
easiest way to do it. If you want to do something more
complicated it might not be possible to do with a GUI, in such
a situation you must use the commandline.
You must remember that there are two different goals. It should
be posible to use the system for a novice. It should be posible
for an experienced user to use the system in an effective way.
For the first goal the GUI is normally the best solution, but
for the second goal the commandline is normally the best
solution.
But again the user interface is not part of the OS, it is
simply an application on the OS. An OS failing to support both
type of applications is a very poor OS.
[...]
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Accessing files from within a kernel module
Date: Fri, 03 Nov 2000 12:28:11 +0100
Karl Heyes wrote:
>
> In article <8ts5k9$lip$[EMAIL PROTECTED]>, "aldo.gavioli"
> <[EMAIL PROTECTED]> wrote:
>
> > I need to read a file from within a kernel module (a pseudo block device
> > driver). The file is a simple ASCII in /opt, I couldn't figure out a metode
> > to open and read from it. I'm trying to open with filp_open() and then read
> > using the read pointed by the file->dentry->inode->file operation structure i
> > get, but the open() fails with error code -14 May it is because I allocate
> > the buffer in kernel space, while I should pass a userspace pointer?
> > I'd really appreciate any hints, thanks.
> >
>
> use the sys_open sys_read functions etc.
>
> karl.
That is probably not the best way to do it, theese functions will
do the opperations on behalf of the current process. That means
sys_open will open the file with the current process permitions,
and the resulting fd will only be usefull within that process.
sys_read will only be able to read from files opened by the current
process, and it will only be able to write to a buffer in the
current process virtual memory.
Error code -14 is -EFAULT which means that a systemcall was called
with an invalid pointer which was expected to point into userspace.
Looking on sys_open in fs/open.c can help understanding what happens.
The filp_open function expects a pointer to a name in kernel space,
so i cannot see why filp_open could ever return -EFAULT, the check
should have been made already when filp_open is called.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Linux in assembly
Date: Fri, 03 Nov 2000 12:48:55 +0100
[EMAIL PROTECTED] wrote:
>
> could it be possible to move some of the linux kernel c stuff into
> assembly ported and fine tuned to each processor so that it
> is fast and efficient? There are technology in this area
> using machine language modules that can be loaded and swapped in
> so that they could be developed in a modular way (like how
> software components like classes in C++ and java work). I believe
> something along the lines of V2_OS but retain the multitasking
> and other virtual memory stuff.
>
> This would speed up the core cycles.
>
> Of course, the other direction that the industry is also following
> is to wait for the microprocessor to catch up to speed. Like
> java, or create a microprocessor that can run native cross cpu
> programs natively (like picojava chips).
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
The overall structure of a system has much greater
influence on speed than the speed of each component.
First you should focus on an overall structure that
gives good speed, when you have found a good
structure you might consider rewriting the parts of
this structure to improve performance. Here there
are lots of isues to think of first. If rewriting a
part into assembler would make the task of changing
the overall structure harder it might not be a good
idea. The overall structure even if quite efective
might still change over time.
You also should consider optimizing compilers, if
the improvement can be done by making the compiler
optimize better that is the right way to go. It
would then help on both kernel and user space
programs, and it might even help in places you
haven't thought about.
If at last you decide to rewrite something into
assembler you should of course choose the parts
that use most CPU time. On most systems major CPU
usage happens in user space, and in some cases in
context switching. You might try to rewrite the
kernel to do faster context switching, but often
it pays better to rewrite user programs spending
to much time on doing syscalls.
--
Kasper Dupont
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
