Linux-Development-Sys Digest #286, Volume #8 Fri, 17 Nov 00 13:13:13 EST
Contents:
Re: raw packet socket; how to retransmit ("Vadim Model")
Re: raw packet socket; how to retransmit ("Vadim Model")
Re: RFC POP (Josef Moellers)
Re: RFC POP (Vincent Deverre)
Re: raw packet socket; how to retransmit (Guy Bolton King)
Re: TCP congestion-avoiding slow start mode ([EMAIL PROTECTED])
Can't find regcmp command ([EMAIL PROTECTED])
Re: raw packet socket; how to retransmit (Grant Edwards)
Re: skeleton driver ("Joachim Rosskopf")
Re: Segmentation faults with struct hostent & char ** (Philip Armstrong)
Best file to download (was: 2.4.0testXX - PCMCIA??) (bill davidsen)
Re: 2.4.0testXX - PCMCIA?? (bill davidsen)
Intel 815E chipset on-board video and Linux Kernel 2.4.0-test11-pre* ("Stephen
Gutknecht \(VW\)")
Re: RFC POP (Villy Kruse)
Re: Can't find regcmp command (Kaz Kylheku)
help with modutils -dynamic unload (Michael Palme)
Re: Problems (re-)building glibc-2.1.2 ("Arthur H. Gold")
----------------------------------------------------------------------------
From: "Vadim Model" <[EMAIL PROTECTED]>
Subject: Re: raw packet socket; how to retransmit
Date: Fri, 17 Nov 2000 15:24:51 +0300
Guy Bolton King wrote in message
>I recently encountered an equivalent problem, which it probably
>wouldn't hurt to be aware of: when injecting packets using the
>PF_PACKET socket interface, it is possible for the driver packet queue
>to become full, at which point packets queued at the packet scheduling
>layer are quietly dropped.
>
>Since the environment I was working could guarantee that only one
>process was using the ethernet device at a time, I crufted up a /proc
>driver that simply dumped the packet drop statistics from the packet
>scheduling layer:
>
> for(pdev = dev_base; pdev && result < MAXFILELEN; pdev = pdev->next){
> result += sprintf(page + result, "%s", pdev->name);
> if(pdev->qdisc){
> result += sprintf(page + result,
>"\t%i\n",pdev->qdisc->stats.drops);
> }
> else{
> result += sprintf(page + result, "*\n");
> }
> }
>
>Whilst this doesn't tell you _which_ packets have been dropped, it at
>least lets you know that _some_ have been dropped. It's far from
>perfect, but perhaps you could extend your ethernet driver to count
>TX failures and do the same sort of thing i.e. tell you that _some_
>packets have failed to transmit.
>
>I guess the full solution to your problem would be to implement a char
>driver interface to your ethernet card and have non-blocking writes
>which would return error on TX failure, bypassing the entire socket
>layer. Of course, this may be overkill for your current requirements.
>
>Guy.
Actually I did something very similar in principle. After write() to raw
packet socket I poll /proc/net/dev file waiting for TX statistics update. If
some TX counter is changed then you can decide what had happened depending
on which counter is changed. It is not elegant, but looks like the only
solution provided that I can not (and actually do not want to, and have no
time to) change anything within the kernel.
If you develop a product for Linux platform it is not acceptable to supply
any patches to kernel to make the product working. IMHO.
Anyway, thank you very much for information. At least I known I'm not alone.
Vadim
------------------------------
From: "Vadim Model" <[EMAIL PROTECTED]>
Subject: Re: raw packet socket; how to retransmit
Date: Fri, 17 Nov 2000 15:29:02 +0300
>Actually it does, otherwise it wouldn't be able to manage the socket
>send buffer. It'll just not help the original poster because there is no
error
So If you allow synchronous write() on such socket, it becomes in principle
possible to return -1 and set errno to something?
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: RFC POP
Date: Fri, 17 Nov 2000 14:14:19 +0100
Vincent Deverre wrote:
> =
> Quelqu'un pourrait il m'envoyer par mail le fichier RFC correspondant a=
u
> protocol POP3
> Merci
I assume you are looking for an RFC covering POP3, although you have a
strange way of asking B-{)
Go to http://www.ietf.org/rfc.html
There is an "RFC Index" which you can search. Then enter the appropriate
RFC number (hint: it's a natural number greater than 1938 and less than
1940 B-{) into the input field on tha main page and ... voila (see, I
even know French B-{)
A votre service,
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Vincent Deverre <[EMAIL PROTECTED]>
Subject: Re: RFC POP
Date: Fri, 17 Nov 2000 14:57:19 +0100
I don't have acces to the Net.
I have only mails.
Josef Moellers a �crit :
> Vincent Deverre wrote:
> >
> > Quelqu'un pourrait il m'envoyer par mail le fichier RFC correspondant au
> > protocol POP3
> > Merci
>
> I assume you are looking for an RFC covering POP3, although you have a
> strange way of asking B-{)
>
> Go to http://www.ietf.org/rfc.html
> There is an "RFC Index" which you can search. Then enter the appropriate
> RFC number (hint: it's a natural number greater than 1938 and less than
> 1940 B-{) into the input field on tha main page and ... voila (see, I
> even know French B-{)
>
> A votre service,
>
> --
> Josef M�llers (Pinguinpfleger bei FSC)
> If failure had no penalty success would not be a prize (T. Pratchett)
--
+===========================================+
Vincent Deverre
T�l : 01.30.03.54.30
Mail:[EMAIL PROTECTED]
+===========================================+
------------------------------
From: Guy Bolton King <[EMAIL PROTECTED]>
Subject: Re: raw packet socket; how to retransmit
Date: Fri, 17 Nov 2000 13:42:29 +0000
Vadim Model wrote:
> ...
> If you develop a product for Linux platform it is not acceptable to supply
> any patches to kernel to make the product working. IMHO.
Yes, but I_M_HO, it _is_ acceptable to provide a kernel module (although
the whole issue of keeping modules portable across kernel versions is a
whole new kettle of ball games).
> Anyway, thank you very much for information. At least I known I'm not alone.
You're welcome.
Guy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TCP congestion-avoiding slow start mode
Date: Fri, 17 Nov 2000 14:24:07 GMT
In article <8v352v$94v$[EMAIL PROTECTED]>,
Jerome Corre <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Where can I find out more about the TCP protocol and this mode?
> Is there a way to know when the slow start is active or inactive
during
> a transmition? is there a way to force this mode constantly? is there
> any other mode?
>
> thanks for any help
>
> Jerome
>
> --
> Jerome Corre
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
I dont understand very well what you are talking about but i think you
are talking about the Van Jacobsen algorithm to minimize congestion on
a tcp/ip network .
You can find information about internet standards here :
http://www.faqs.org/rfcs/
----
Julien VANEGUE
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Can't find regcmp command
Date: Fri, 17 Nov 2000 14:40:52 GMT
I'm porting an app which runs on Unixware and Solaris. On those
platforms there is a command /bin/regcmp which compiles regular
expressions and outputs them as C character array assignments - for
example:
/* ".*([0-9][a-zA-Z]{3}[0-9]{5}[a-zA-Z]{3})$0$" */
char COMMON_CODE[] = {
0101,074,00,0120,04,060,020,071,0123,07,0141,020,
0172,0101,020,0132,03,03,0123,04,060,020,071,05,
05,0123,07,0141,020,0172,0101,020,0132,03,03,014,
00,00,034,064,
0};
Adding these to your program's source code means that you don't have to
call regex in your program.
However I can't find the regcmp command on RedHat Linux 6.2.
Furthermore the definitions of the compiled expression (which is passed
to regex) seems to be a structure with several elements, whereas on
Unixware and Solaris it just appears to be a simple character array.
If there is no regcmp command in Linux, how do I precompile regular
expressions so that they can be added to my source code and passed into
regex() calls?
Thanks
Colin
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: raw packet socket; how to retransmit
Date: Fri, 17 Nov 2000 15:22:10 GMT
In article <8v2ks2$1cb9$[EMAIL PROTECTED]>, Vadim Model wrote:
>> 1) The ethernet driver doesn't know who requested the packet
>> be sent.
>>
>> 2) If it did, there isn't a well-defined way (other than a
>> signal) to inform an application of an asynchronous error
>> like that.
>
>
>Yes. Actually this is exactly what I see looking into kernel. I
>know this is just a design issue of any UNIX. Sometimes I see
>that UNIX is quite well designed but there are some solutions
>which could not be easily implemented in any UNIX platform.
>BTW: In the situation we are talking about, Windows NT/2000 is
>much more convenient: it associates a request with every packet
>sent via similar packet interface, so that you can synchronize
>execution with completion of requests processing and obtain
>status of transmission: OK or NOT.
Unix tends to err on the side of simplicity. WinNT, OTOH, is
from the VMS school: try to implement all the features any OS
designer has ever thought of plus another dozen they haven't.
The result is that writing a driver for NT is an order of
magnitude more work than writing one for Unix -- and the
results under NT are less stable and harder to test.
>And of course I do not want anybody to rewrite the whole Linux
>kernel. I just asked if there is something in Linux which I do
>not see. Looks like there is no "undocumented" feature which
>would help me.
I'm pretty sure there isn't. One thing you _could_ do that
wouldn't be a horrendous amount of work is hack an Ethernet
driver to implement a second, low level, API that does nothing
but send a packet and return the status to the caller. I've
actually done this type of thing under another OS: written an
Ethernet driver has two APIs. The first is the standard API
used by the IP stack, the second is a low level MAC addressing
mode API for use by applications like yours.
All you have to do is add a table of service routines
(open/close/write are all you'd need) and register them with
the kernel. The write() call would wait until the Tx hardware
is available, send the packet, check the Tx status, and return.
--
Grant Edwards grante Yow! YOW!! Everybody out
at of the GENETIC POOL!
visi.com
------------------------------
From: "Joachim Rosskopf" <[EMAIL PROTECTED]>
Subject: Re: skeleton driver
Date: Fri, 17 Nov 2000 18:18:00 +0100
In article <8v0tu2$mmt$[EMAIL PROTECTED]>, "Massimiliano Caovilla"
<[EMAIL PROTECTED]> wrote:
> Hi to all,
> I'm trying to write a driver to support a particular kind of MO disk
> drive; they behave halfway between hard drives and cdrom, and are
> connected throught a scsi interface, so my first idea was to write the
> code starting from the sr driver wich is included in the kernel: the
> problem is that sr has a static major number already assigned to it,
> while I need to get my numbers dinamically allocated, thus I changed the
> code as little as I could to get register_blk_device called with major 0
> and be assigned a major as return value.
> Now, I'm experimenting with a real scsi cdrom wich gets attached by the
> original sr0 and by my version, but can get mounted only by the original
> version!
> (the mount command on my sr0 hangs in loop and can't be stopped without
> a
> kill, after the open is performed on my module)
> I can't figure out where the problem sits, as the only thing I modified
> is
> the policy of major number assignment... the only thing I can think is
> that
> "my" sr is still dependent on it's original major number or that there's
> something wrong with the nodes (that are generated by a script when I
> insmod the module, so they can have the right major)
> Couldn't you suggest a kind of "skeleton driver" or some other driver
> that
> would be easier to modify, or some other source of info about scsi cdrom
> block devices?
> I have a book by Alessandro Rubini on device drivers, but it's useless
> in
> this case.
> Could you please suggest a strategy to trace the mount operation, so I
> can
> figure out when and where it gets stuck?
> Maybe a kernel debugger?
>
> Any help will be REALLY appreciated!
>
> Ciao, Massi
>
> p.s. excuse my wordiness!
>
>
Hello,
check out the resource of devfs, it will slove your problem in very
sofistiacted way. And you are on the right way for the future.
Here is a little tutorial (Also by Mr. Rubini *g*)
http://www.linux-mag.com/2000-05/gear_01.html
CU
Joachim
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Crossposted-To: comp.os.linux.development
Subject: Re: Segmentation faults with struct hostent & char **
Date: 17 Nov 2000 09:57:02 -0000
In article <8v1du8$c23$[EMAIL PROTECTED]>,
Christoper McClan <[EMAIL PROTECTED]> wrote:
>I've since discovered "malloc". Can't believe you have to assign
>memory yourself!
Welcome to C. Please note that in giving you the ability to finely
control the memory allocation your program carries out, we have also
given you the ability to shoot yourself in the foot as often as you
like. We hope you will appreciate our generosity.
If you don't like having to allocate memory yourself, then I suggest
that you use a programming language that does it for you like Java.
"Good workers choose the appropriate tool for their job" ought to be a
corollary to "Bad workers always blame their tools" IMO :)
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Best file to download (was: 2.4.0testXX - PCMCIA??)
Date: 17 Nov 2000 16:17:45 GMT
The pre-release of test kernels, such as test11-pre6, now include a
testXX.log file, which highlights the changes. Bravo!! I see that both
my problems have been addressed (I won't say fixed until I try), so I
can get enough apm in an SMP machine to turn it off when the UPS gets
low. I'd like suspend mode, but I take what I can get...
And my PCMCIA may work, ask and receive.
Very seriously, the log file is vastly useful, and I think it is worth
reading even if you don't run bleeding edge kernels, just so you can
say "ah-ha, that's a known and fixced problem." I hope this is a
permanent feature to the testing process. Thank you!
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
Make the rules? I don't make the rules. I don't even FOLLOW the rules!
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: 2.4.0testXX - PCMCIA??
Date: 17 Nov 2000 16:20:38 GMT
In article <[EMAIL PROTECTED]>,
Paul Kimoto <[EMAIL PROTECTED]> wrote:
| In article <Rz_P5.4867$[EMAIL PROTECTED]>, bill davidsen wrote:
| > I have compiled a 2.4.0test10 (and many earlier kernels) with PCMCIA
| > enabled in the kernel, pcmcia3.1.21, etc. However, the kernel simply
| > doesn't have a pcmcia device in /proc, and cardmgr doesn't work.
|
| There isn't anything called "pcmcia" in the 2.2.* /proc either (see below).
| Or do you mean /proc/bus/pccard?
|
| > Also,
| > pcmcia-cs doesn't generate a pcmcia-core module to provide the services
| > which are missing from the kernel.
|
| You don't need to have one, I believe (see below again).
|
| > I turned on all the pcmcia options in the kernel, and 16 and 32 bit.
|
| On my 2.4.0-test* (UP) laptop, I have
|
| CONFIG_PCMCIA=y
| CONFIG_CARDBUS=y
| CONFIG_NET_PCMCIA=y
| CONFIG_PCMCIA_3C574=m
| CONFIG_PCMCIA_SMC91C92=y
| CONFIG_PCMCIA_NETCARD=y
| CONFIG_PCMCIA_SERIAL=y
| CONFIG_PCMCIA_SERIAL_CS=m
|
| "They" say that you should use CONFIG_CARDBUS if you have Cardbus-aware
| hardware. Also it might be useful to consult David Hinds's README-2.4 file
| that comes with pcmcia-cs.
Thanks for the feedback. I see that there has been work in the
test11-pre series on both apm with SMP and PCMCIA. I suspect that this
is why mine doesn't work, and I will try the newest version tonight.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
Make the rules? I don't make the rules. I don't even FOLLOW the rules!
------------------------------
From: "Stephen Gutknecht \(VW\)" <[EMAIL PROTECTED]>
Subject: Intel 815E chipset on-board video and Linux Kernel 2.4.0-test11-pre*
Date: Fri, 17 Nov 2000 08:47:52 -0800
Anyone able to get this to work? I can't get agpgart to work ...
There is one other person [EMAIL PROTECTED] who reports same problem.
I have put together instructions on how I am doing my kernel build under
Redhat 7.0:
http://www.roundsparrow.com/Linux/240oni815/
Please help if you are trying the same.
Stephen Gutknecht
Renton, Washington
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: RFC POP
Date: 17 Nov 2000 16:52:27 GMT
On Fri, 17 Nov 2000 13:00:27 +0100,
Vincent Deverre <[EMAIL PROTECTED]> wrote:
>Quelqu'un pourrait il m'envoyer par mail le fichier RFC correspondant au
>protocol POP3
>Merci
>
No 1939 suplemented by 1957. 1939 has severeal obsoleted prdecessors.
Villy
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Can't find regcmp command
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Nov 2000 16:51:30 GMT
On Fri, 17 Nov 2000 14:40:52 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>I'm porting an app which runs on Unixware and Solaris. On those
>platforms there is a command /bin/regcmp which compiles regular
>expressions and outputs them as C character array assignments - for
>example:
>
>/* ".*([0-9][a-zA-Z]{3}[0-9]{5}[a-zA-Z]{3})$0$" */
>char COMMON_CODE[] = {
>0101,074,00,0120,04,060,020,071,0123,07,0141,020,
>0172,0101,020,0132,03,03,0123,04,060,020,071,05,
>05,0123,07,0141,020,0172,0101,020,0132,03,03,014,
>00,00,034,064,
>0};
>
>Adding these to your program's source code means that you don't have to
>call regex in your program.
This is the first I'm hearing of this utility.
>If there is no regcmp command in Linux, how do I precompile regular
>expressions so that they can be added to my source code and passed into
>regex() calls?
You cannot. You must call regcomp on static regex_t objects when your program
performs its global initializations. This shouldn't be a serious performance
hit unless your program has many thousands of complex regular expressions to
compile---that's probably what the utility is intended for.
------------------------------
From: Michael Palme <[EMAIL PROTECTED]>
Subject: help with modutils -dynamic unload
Date: Fri, 17 Nov 2000 17:03:06 GMT
hello.....
ive got modutils 2.3.19 running on kernel 2.2.16. if i load some
modules with modprobe -k or some selfprogrammed modules with kmod
(alias entry for that modules in modules.conf) i cant unload them with
rmmod -a or modprobe -r. i wonder about that cause they are listed as
unused and autoclean. with the modules from the original kernel the
dynamic unload works (i.e. the floppy module).
please can anybody figure out how to make that feature work
(respectively how to implement it in my modules).
thanks a lot .... Michael Palme
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 17 Nov 2000 12:18:45 -0600
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: Re: Problems (re-)building glibc-2.1.2
"Arthur H. Gold" wrote:
>
> Perhaps someone could shed some light on this:
>
> I have a (slightly) patched version of glibc-2.1.2 (the
> patches are mainly concerned with exposing some low-level
> symbols), which I've built in the past with no problems.
>
> Now, unfortunately, the build is dying on an "undefined
> reference to __libc_global_ctors" in the newly-built ld.so
> (in the `elf' subdirectory).
>
> Any clues?
>
> Many thanks.
> --ag
OK. Found the solution...I had to downgrade my binutils.
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account
for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
"Curiousity didn't kill _this_ cat"
-- Studs Terkel, upon being asked what he thinks his epitaph
should be.
------------------------------
** 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
******************************
