Linux-Development-Sys Digest #355, Volume #8 Sun, 17 Dec 00 09:13:09 EST
Contents:
Re: IPC in a module (noone@[127.11.12.13])
Re: IPC in a module ("Gareth Stephens")
IP_PKTINFO ("pozzugno")
Re: Compiling C++ programs with GCC --> no GPL license implications (Austin Ziegler)
Re: Compiling C++ programs with GCC --> no GPL license implications (jbs)
Re: how to use raw device ("Norman Dresner")
Re: A faster memcpy and bzero for x86 (Robert Redelmeier)
Re: how to use raw device (Kaz Kylheku)
Re: IPC in a module ("Gareth Stephens")
Re: A faster memcpy and bzero for x86 (Linus Torvalds)
Re: Allocating memory for multiple pages (Wolfram Faul)
gnat ADA95 (Marvin Hoffmann)
Re: A faster memcpy and bzero for x86 (Robert Redelmeier)
Re: A faster memcpy and bzero for x86 (Robert Redelmeier)
----------------------------------------------------------------------------
From: noone@[127.11.12.13]
Crossposted-To: uk.comp.os.linux,uklinux.help.misc
Subject: Re: IPC in a module
Date: 16 Dec 2000 14:32:06 +0000
"Gareth Stephens" <[EMAIL PROTECTED]> writes:
> Perhaps if I explain a little better. What I am trying to do is the
> following. There are two character special files one to write into and
> the other to read from. A program writes into one of them and a daemon
> reads from the other end. Basically what I want to do is queue the
> messages until such time as something is ready to read them, hence the
> reason I thought SYSV message queues looked ideal.
That doesn't sound like you need any interprocess communication
mechanism at all, just have the device driver queue the messages
in a kernel buffer until such time as they are read.
How about something (a lot simpler than) /usr/src/linux/fs/pipe.c,
basically, you need a read and write function that add and
subtract items from a queue.
However, it would still be possible for netlink to provide
this function...
Paul
------------------------------
From: "Gareth Stephens" <[EMAIL PROTECTED]>
Subject: Re: IPC in a module
Date: Sat, 16 Dec 2000 15:01:26 +0000
Hi,
Thanks for the info, that's all I wanted to know, as I mentioned I
didn't want anyone to give me the answer as I obviously wouldn't learn
anything, however asking for help isn't cheating so you can help me! :)
It's not really any different to reading a book is it?
Anyway sorry getting carried away again, once again thanks for the info
that's all I needed to know.
Cheers,
Gareth.
In article <[EMAIL PROTECTED]>, "Peter T. Breuer"
<[EMAIL PROTECTED]> wrote:
> In comp.os.linux.development.system Gareth Stephens
> <[EMAIL PROTECTED]> wrote:
>> Yes I do know that this is a somewhat convoluted way to do it (i.e.
>> why
>> not write directly to a message queue and have the other process read
>> from that there by cutting out the device driver bit altogether) _but_
>> I have to do it this way for an assignment. All I really need to know
>> is:
>
> Ah, well in that case we can't help you!
>
>> a) Is it possible
>
> Yes, obviously. But not using "IPC message queues". What you are being
> asked to do is implement a simple sort of message queue. So simple, in
> fact, that only a few lines of code in the kernel are required.
>
>> b) If so where should I start looking (I _don't_ expect code ready to
>> slot
>
> You should think about it instead. You just want one character driver
> that writes into the end of an internal queue (=circular buffer,
> probably) in the kernel, and another that reads from it. SO you should
> look at character drivers in rubini's book.
>
>> c) If it's not possible is there another ready made way, or should I
>> just use a queue/linked list?
>
> Obviously! I'd use a circular 4KB buffer and block when it's full (and
> empty, on read).
>
> Peter
------------------------------
From: "pozzugno" <[EMAIL PROTECTED]>
Subject: IP_PKTINFO
Date: Sat, 16 Dec 2000 15:53:09 GMT
Hi!
I read from man 4 ip these lines (about SOCKET OPTIONS):
---
IP_PKTINFO
[...]
If IP_PKTINFO is passed to sendmsg(2) then the out-
going packet will be sent over the interface speci-
fied in ipi_ifindex with the destination address
set to ipi_spec_dst
---
So, if I have a computer with two network interfaces:
eth0 ---> 192.168.1.1
eth1 ---> 192.168.2.1
I can create a UDP packet with 192.168.2.1 destination, but
transmitting the packet by eth0 and then receving on eth1.
I wrote these lines (buffer is a pointer to payload, daddr is
destination address (192.168.2.1), pktinfo is struct in_pktinfo
(pktinfo.ipi_ifindex is eth0, pktinfo.ipi_spec_dst is router for
192.168.1.0 (for example, 192.168.1.100)):
---
void
send_pckt( unsigned int size ) {
struct iovec tmpbuffer;
struct msghdr *msg=(struct msghdr*)malloc(sizeof(struct msghdr));
struct cmsghdr *cmsg;
tmpbuffer.iov_base = buffer;
tmpbuffer.iov_len = size;
msg->msg_name = &daddr;
msg->msg_namelen = sizeof(struct sockaddr_in);
msg->msg_iov = &tmpbuffer;
msg->msg_iovlen = 1;
msg->msg_flags=0;
/**** BUG *****/
msg->msg_controllen = sizeof(struct cmsghdr)+sizeof(struct in_pktinfo);
msg->msg_control = malloc(sizeof(struct cmsghdr)+sizeof(struct
in_pktinfo));
cmsg = CMSG_FIRSTHDR(msg);
cmsg->cmsg_len = CMSG_LEN( sizeof(struct in_pktinfo) );
cmsg->cmsg_level = SOL_IP;
cmsg->cmsg_type = IP_PKTINFO;
memcpy( CMSG_DATA(cmsg), &pktinfo, sizeof(struct in_pktinfo) );
msg->msg_controllen = CMSG_SPACE( sizeof(struct in_pktinfo) );
/**** BUG *****/
if( sendmsg( sckt, msg, 0 )!=size )
fprintf( stderr, "error: %s\n", strerror(errno) );
---
I receive an "Invalid argument" error from sendmsg. Why?
If I delete lines between /**** BUG ****/ and set
msg->msg_controllen=0, then no error occurs.
Thanks in advance for the help.
------------------------------
Crossposted-To: gnu.misc.discuss,comp.lang.c++
From: Austin Ziegler <[EMAIL PROTECTED]>
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Sat, 16 Dec 2000 12:01:00 -0500
On Fri, 15 Dec 2000, jbs wrote:
> Pete Becker wrote:
>> There is a difference between "I know what this means" and "There could
>> be problems here." The former is a legal judgment. The latter is not.
> The former is a useful statement. The latter is not.
And if the former is, in fact, incorrect or in conflict with the law...
-f
--
austin ziegler * fant0me(at)the(dash)wire(d0t)c0m * Ni bhionn an rath ach
ICQ#25o49818 (H) * aziegler(at)s0lect(d0t)c0m * mar a mbionn an smacht
ICQ#21o88733 (W) * fant0me526(at)yah00(d0t)c0m * (There is no Luck
AIM Fant0me526 *-s/0/o/g--------&&--------s/o/0/g-* without Discipline)
Toronto.ON.ca * I speak for myself alone *-----------------------
------------------------------
From: jbs <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss,comp.lang.c++
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Sat, 16 Dec 2000 09:18:41 -0800
Austin Ziegler wrote:
> On Fri, 15 Dec 2000, jbs wrote:
> > Pete Becker wrote:
> >> There is a difference between "I know what this means" and "There could
> >> be problems here." The former is a legal judgment. The latter is not.
> > The former is a useful statement. The latter is not.
>
> And if the former is, in fact, incorrect or in conflict with the law...
Then you might, as always, be screwed by relying on it. Always consider
the credibility of your source. Always.
------------------------------
From: "Norman Dresner" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,linux.dev.kernel
Subject: Re: how to use raw device
Date: Sat, 16 Dec 2000 17:46:06 GMT
Ronald Cole <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Josef Moellers <[EMAIL PROTECTED]> writes:
> > ca depend, as the French use to say.
> >
> > It depends on which kernel version you use. 2.2 kernels don't have raw
> > devices.
>
What advantages does this give you?
Norm
------------------------------
Date: Sat, 16 Dec 2000 11:59:50 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86
Linus Torvalds wrote:
>
> It's not just about polluting the caches.
>
> It's also about polluting a shared bus, where the other CPU's that
> aren't idle may be doing real work that _needs_ that bus.
Well, there's something stinky happening anyways :)
The asm program below tests various bzero routines and
outputs four times in CPU clocks : a userland 4kB bzero
with `rep stosl`, the [g]libc 4kB bzero, the time for a
second 32bit write and the time for the first 32bit write
to an otherwise unused RAM page.
Typical times are: [Abit BP6, 2 * 5.5 * 94 MHz Celerons]
Linux 2.4.0t8: 847 915 33 12000 (~15% at 25000)
FreeBSD 4.1: 1030 11000 33 5000 (all variable 15%)
notes: (1) (2) (3) (4)
1) This time could be improved to 811 with MMX moves, a
4% improvement likely to cost much more for MMX context saves.
AMD K7 may perform differently. The worst 32bit code I could
write in good conscience took 2100, the best 1600. Why FBSD
has variable times for a single instruction is a mystery.
2) The glibc bzero routine is d@mn good! It ought not
to be so deprecated. The FreeBSD libc bzero routine s#x.
3) 33 CPU cycles is exactly as expected: 32 clocks for rdtsc
[measurement] overhead, and 1 clock for a single write to L1
cache which was brought in by the first [long] write.
4) The first write to a page is always long because of the
copy-on-write VM philosophy. The OS has to scrounge a freeable
page. But Linux takes considerably longer. Why? Fragmentation?
It should bzero rather than memcpy the zeropage. Most (>90%) CoW
pagefaults are undoubtedly from the zeropage, and a memcpy
would do nothing but eat cycles and pollute the caches!
-- Robert author `cpuburn` http://users.ev1.net/~redelm
# bzerock - Check block zero timing
# Copyright 2000 RJ Redelmeier Licenced under GNU GPL 2.0
# compile: gcc -s -o bzerock bzerock.s
# outputs 4 numbers, all in CPU clocks (1000 times):
# user_bzero glibc_bzero second_write first_write
#
.globl main
main:
movl $buf, %edi
addl $4096, %edi
andl $-4096, %edi
again:
xorl %ebx, %ebx
rdtsc
xchgl %ebx, %eax
movl %eax, (%edi)
rdtsc
subl %ebx, %eax
pushl %eax
xorl %ebx, %ebx
rdtsc
xchgl %ebx, %eax
movl %eax, 4(%edi)
rdtsc
subl %ebx, %eax
pushl %eax
xorl %ebx, %ebx
rdtsc
pushl %eax
pushl $4096
pushl %edi
call bzero
addl $8, %esp
rdtsc
popl %ebx
subl %ebx, %eax
pushl %eax
movl $1024, %ecx
xorl %ebx, %ebx
rdtsc
xchgl %ebx, %eax
rep
stosl
rdtsc
subl %ebx, %eax
pushl %eax
pushl $fmt
call printf
addl $20, %esp
decl count
jnz again
call exit
.data
count: .long 1000
fmt: .asciz " %d %d %d %d \n"
.bss
.lcomm buf, 4<<20
--
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,linux.dev.kernel
Subject: Re: how to use raw device
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Dec 2000 17:56:56 GMT
On Sat, 16 Dec 2000 17:46:06 GMT, Norman Dresner <[EMAIL PROTECTED]> wrote:
>Ronald Cole <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Josef Moellers <[EMAIL PROTECTED]> writes:
>> > ca depend, as the French use to say.
>> >
>> > It depends on which kernel version you use. 2.2 kernels don't have raw
>> > devices.
>>
> What advantages does this give you?
You mean raw devices? They are useful to database freaks who want to implement
their own buffering and their own access optimizations. A block buffering layer
above the device is not only overhead but may make some of their algorithms
useless or superfluous.
Databases that run on proprietary UNIX systems do use the raw devices;
when ported to Linux, these applications could benefit if they could
also use raw devices in that environment.
------------------------------
From: "Gareth Stephens" <[EMAIL PROTECTED]>
Subject: Re: IPC in a module
Crossposted-To: uk.comp.os.linux,uklinux.help.misc
Date: Sat, 16 Dec 2000 18:16:56 +0000
Hi again,
Thanks for the advice, having thought about it again a pipe or some sort of
queue looks like the obvious choice (now :).
Cheers,
Gareth.
In article <[EMAIL PROTECTED]>, noone@[127.11.12.13] wrote:
> "Gareth Stephens" <[EMAIL PROTECTED]> writes:
>
>> Perhaps if I explain a little better. What I am trying to do is the
>> following. There are two character special files one to write into and
>> the other to read from. A program writes into one of them and a daemon
>> reads from the other end. Basically what I want to do is queue the
>> messages until such time as something is ready to read them, hence the
>> reason I thought SYSV message queues looked ideal.
>
> That doesn't sound like you need any interprocess communication
> mechanism at all, just have the device driver queue the messages in a
> kernel buffer until such time as they are read.
>
> How about something (a lot simpler than) /usr/src/linux/fs/pipe.c,
> basically, you need a read and write function that add and subtract
> items from a queue.
>
> However, it would still be possible for netlink to provide this
> function...
>
> Paul
------------------------------
From: [EMAIL PROTECTED] (Linus Torvalds)
Subject: Re: A faster memcpy and bzero for x86
Date: 16 Dec 2000 12:06:35 -0800
In article <[EMAIL PROTECTED]>, Robert Redelmeier <[EMAIL PROTECTED]> wrote:
>
>4) The first write to a page is always long because of the
>copy-on-write VM philosophy. The OS has to scrounge a freeable
>page. But Linux takes considerably longer. Why? Fragmentation?
>It should bzero rather than memcpy the zeropage. Most (>90%) CoW
>pagefaults are undoubtedly from the zeropage, and a memcpy
>would do nothing but eat cycles and pollute the caches!
Under Linux, the above is not a COW-fault at all: Linux will not
populate the page tables with zero pages, so Linux will get a "nopage"
fault and will build up the page tables at run-time. Linux will notice
that it's a write, allocate a new page, and clear it.
I'll see if I can see anything obvious from the profile.
I suspect that FBSD might be pre-allocating pages.
Linus
------------------------------
From: Wolfram Faul <[EMAIL PROTECTED]>
Subject: Re: Allocating memory for multiple pages
Date: Sat, 16 Dec 2000 21:23:46 +0100
Hallo,
and here is URL for it
http://www.polyware.nl/~middelin/hob-v4l.html
Marc SCHAEFER wrote:
>
> Kang Mo Yang <[EMAIL PROTECTED]> wrote:
> : I need to allocte a size like 4MBytes.
>
> bigphysarea
--
Wolfram Faul
TU-Muenchen
[EMAIL PROTECTED]
------------------------------
From: Marvin Hoffmann <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: gnat ADA95
Date: Sat, 16 Dec 2000 23:09:02 +0100
gnat 3.13p doesnt work.
I get this error when I start gnatmake: error in loading shared libraries
libgnat-3.13p.so.1: No such file or directory.
I've installed it with an rpm on Suse 7.0!
any Ideas?
--
------------------------------
Date: Sat, 16 Dec 2000 20:16:48 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86
Linus Torvalds wrote in small part:
>
> I suspect that FBSD might be pre-allocating pages.
That's why my code reports on 1000 pages. There's quite
some variation in the FreeBSD 4.1 times (+/-15%), but no
systematic increase from 5000 CPU clocks.
I did see a large increase on FBSD 3.3 for first pagewrites:
The first ~30 pages took only ~3000 clocks IIRC, but after
that they took 11000 each! That smells like pre-allocation
to me. But the lil'daemons have been busy on their code,
and chopped it out.
-- Robert
------------------------------
Date: Sat, 16 Dec 2000 21:02:49 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86
Linus Torvalds wrote in part:
> I'll see if I can see anything obvious from the profile.
Well, I've looked at the 2.4.0t8 kernel (the best way for me
to understand it is `objdump -d /usr/src/linux/vmlinux | more`)
and memset looks healthy.
It uses `rep movsb` instead of the slightly faster `rep movsl` but
that only costs 16 extra CPU cycles 2% (863 vs 847) per 4KB zero.
Hardly worth any special-size code.
-- Robert
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
