Linux-Development-Sys Digest #621, Volume #6 Tue, 13 Apr 99 20:14:19 EDT
Contents:
Re: asynchronous disk I/O (Karl Heyes)
Re: M-systems binary only drivers & GPL (H. Peter Anvin)
Re: CD wont't play after 2.0.36->2.2.5 (Robert Schiele)
Re: a problem with scanf (Francesc Oller)
Re: Linux Debugger/Monitor (David Grothe)
Re: Win32 support in Linux (Tristan Tarrant)
Re: SIGPOLL on socket errors (Andi Kleen)
Re: M-systems binary only drivers & GPL (Alexander Viro)
Re: Kernel problem (PANIC) (Rik van Riel)
Re: SMP Linux, Any Catches? (Michael Meissner)
Re: Insure++ questions. (Carlos Vidal)
Parallel port access using parport device (Dirk Lattermann)
Re: persistent heap design advice please ("dave madden")
Re: asynchronous disk I/O (Rik van Riel)
Re: M-systems binary only drivers & GPL (David Grothe)
Re: linux 2.2.5, SMP, device driver (Lorenz Hahn)
Re: a problem with scanf (Steve Summit)
Re: M-systems binary only drivers & GPL (Alexander Viro)
Re: PROC-fs, Need to make it CHARGEBEL (Andi Kleen)
Re: Is use of WINE acceptable for a short-term implementation of ThinkPad Modem?
(Andi Kleen)
Re: a problem with scanf (Francesc Oller)
----------------------------------------------------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: asynchronous disk I/O
Date: Tue, 13 Apr 1999 12:51:46 +0100
[EMAIL PROTECTED] wrote:
> Hi there,
>
> Can anyone confirm that Linux does not support asynchronous disk I/O? On AIX
> and Digital Unix we have system calls like lio_listio(), but I cannot find
> anything similar to that.
>
I believe the true names are something like aio_* which are in the glibc2.1.
not sure
if it's posix or unix98 standard.
karl
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: M-systems binary only drivers & GPL
Date: 13 Apr 1999 19:01:15 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED] (Fabrice Bellard)
In newsgroup: comp.os.linux.development.system
>
> This disk-on-chip is not like an IDE drive, so it needs a special
> block driver. The driver is provided by M-Systems in binary form only.
>
> Since this disk-on-chip is used for booting, the binary Linux driver
> is statically linked with the Linux kernel (it is *not* a module).
>
> My question is: is it legal ? Do Linus & the other copyright holders
> of Linux allow that a binary only driver is statically linked with the
> kernel ?
>
The answer is NO, it is NOT legal. However, the assumption that you
cannot use a module for booting is incorrect; you need to use an
initrd; then you can load the module before you mount your root
filesystem.
-hpa
--
"The user's computer downloads the ActiveX code and simulates a 'Blue
Screen' crash, a generally benign event most users are familiar with
and that would not necessarily arouse suspicions."
-- Security exploit description on http://www.zks.net/p3/how.asp
------------------------------
From: Robert Schiele <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: CD wont't play after 2.0.36->2.2.5
Date: Tue, 13 Apr 1999 21:24:01 +0200
Michael Spalinski wrote:
>
> After upgrading the kernel as in the subject, I can no longer play a CD
> through the sound card (everything worked OK with 2.0.36). This happens on
> a machine which has a SCSI CDROM drive, while on another machine here,
> which has a non-SCSI drive (and the same sound card) everything is fine
> (although 2.2.0 had the same problem there too).
>
> The SCSI controler is Mylex BT958, and the Sound Card is SB16. I can mount
> /dev/cdrom etc without problems (the correct module gets
> inserted). Furthermore xplaycd (and other cd-players) recognizes that a CD
> with the right number of tracks is there and "thinks" it is playing it: no
> sound however is to be heard ...
>
> Any ideas?
>
> M.
Seems that your CDIN volume is set to zero. Try to increase CDIN volume
with a utility (e.g. xmix).
Robert
------------------------------
From: Francesc Oller <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: a problem with scanf
Date: Tue, 13 Apr 1999 21:12:18 +0200
Reply-To: [EMAIL PROTECTED]
Steve Summit wrote:
> In general, scanf has to read ahead a bit to find the *end* of
> the sequence it's trying to match with a %-specifier. (This fact
> is, of course, the source of many of scanf's quirks and foibles.)
> I'm not sure why scanf should be reading ahead on %c, and in fact
> on the first system I tried it it didn't (that is, Francesc's
> code worked "as expected", after replacing tty_raw(0) with
> system("stty raw") ). But when I tried it on a nearby Linux
> system, it did in fact wait for a second character.
>
> This may indicate a slight bug in the GNU/Linux libc, although
> the workaround is exquisitely simple in this case: just use
> getchar, which is what you probably wanted to use all along.
> (In general, scanf %c is a lousy substitute for getchar.)
>
> Steve Summit
> [EMAIL PROTECTED]
Have you tried it on libc5 or libc6 (aka glibc 2)?
It failed for me on libc5 (a very old Slackware box)
For me it may be the symptom of more scanf problems
(in Linux libc5/6 at least). Please take note of the following
very simple code:
int i;scanf("%d%*c",&i);
user input: 345\n
scanf should read 345 (i==345), eat \n and return (input format
exausted). No so in my linux box, scanf keeps reading. It works
as expected on MS-DOS Borland tcc,HP-UX and SunOS5 (solaris).
If it is a bug, should be reported to the libc mantainers.
Francesc Oller
------------------------------
From: David Grothe <[EMAIL PROTECTED]>
Subject: Re: Linux Debugger/Monitor
Date: Tue, 13 Apr 1999 15:09:49 -0500
Reply-To: [EMAIL PROTECTED]
Download
ftp://ftp.gcom.com/pub/linux/src/gdbstub-2.0.36/gdbstub-2.0.36.tgz for
two-machine serial line GDB execution of kernel code. In the 2.0 kernel
physical memory addresses == virtual memory addresses so accessing your
on-board memory is straightforward. If you board memory is at high
addresses (as in for PCI devices) you will need to map the memory first
and then access it via the resulting virtual address both in your driver
and with the debugger.
I'm not sure that GDB can access I/O ports in remote debug mode.
-- Dave
Coen Verkuyl wrote:
> I'm looking for a debug tool for Linux (i386). I'm writing driver
> software
> for a ISA card with memory and registers mapped into the memory space
> of the
> PC. The debug tool must be able to access any physical memory address,
> just
> like the MS-DOS tool 'debug'.
>
> Where can I find something like this?
>
> Thanks for any help,
>
> Coen
> [EMAIL PROTECTED]
------------------------------
From: Tristan Tarrant <[EMAIL PROTECTED]>
Subject: Re: Win32 support in Linux
Date: 13 Apr 1999 13:31:43 GMT
[EMAIL PROTECTED] wrote:
> Well of cource not. I am not that uneducated. I just did not see
> support for it in the kernel config, that's all. Also, now I can't get
It's part of the VFAT filesystem.
> disks from among all my stuff. So, what fs specifyer do I use for
> 'mount'? 'fat32'? I would guess so, but if anyone knows the specifics,
Just use vfat as before. vfat will automatically recognize FAT16 and FAT32
partitions.
Tristan
--
Tristan Tarrant [EMAIL PROTECTED]
Il software e' come il sesso. E' meglio|Software is like sex. It's better
quando e' libero. |when it's free.
Linus Torvalds
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: SIGPOLL on socket errors
Date: 13 Apr 1999 19:24:01 +0200
[EMAIL PROTECTED] (Paul Vojta) writes:
> An error condition on a socket is a pollable event.
>
> A SIGPOLL signal is supposed to be (optionally) sent when a pollable event
> occurs.
>
> However, I have been unable to get a SIGPOLL event to be sent when
> an error condition occurs on a socket. I have been able to get such
> signals to be generated when the socket becomes readable and when the
> write buffer stops being full. I have also had no troubles on SunOS 4.1.4.
>
> Is this a bug in Linux, or have I missed something?
Linux sends SIGIO (=SIGPOLL)[1] when an error connection occurs on a
socket, but only for hard errors (hard error in TCP context means
timeout or error during connection setup). I am not aware of
any bugs in this area in 2.2, early 2.0 missed a few SIGIO cases
though.
If you think something is wrong please post a short program that
shows it.
-Andi
[1] Linux uses BSD terminology here.
--
This is like TV. I don't like TV.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: M-systems binary only drivers & GPL
Date: 13 Apr 1999 15:47:47 -0400
In article <7f049r$lcv$[EMAIL PROTECTED]>,
H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> This disk-on-chip is not like an IDE drive, so it needs a special
>> block driver. The driver is provided by M-Systems in binary form only.
>>
>> Since this disk-on-chip is used for booting, the binary Linux driver
>> is statically linked with the Linux kernel (it is *not* a module).
>
>The answer is NO, it is NOT legal. However, the assumption that you
>cannot use a module for booting is incorrect; you need to use an
>initrd; then you can load the module before you mount your root
>filesystem.
Ahem... Actually it may depend. If it's 90K binary-only firmware + 20 lines
of C code feeding it into the card... AFAICS in such case it would be legal,
even if statically linked. Another case (though pretty unlikely in such
situation): huge finite automate (stored in array of structures) + tiny engine
on C interpreting it.
To be serious, we already have tons of binary stuff in drivers/scsi/
and IIRC that's where the largest files live. Let's see:
$ cd /usr/src/linux
$ du `find -size +200k`|sort -r
556 ./drivers/scsi/advansys.c
540 ./drivers/net/myri_code.h
513 ./Documentation/Configure.help
383 ./drivers/net/acenic_firmware.h
371 ./drivers/scsi/aic7xxx.c
354 ./drivers/net/dgrs_firmware.c
312 ./drivers/scsi/FlashPoint.c
296 ./drivers/scsi/sym53c8xx.c
281 ./drivers/scsi/ncr53c8xx.c
211 ./drivers/net/ptifddi_asm.h
204 ./drivers/scsi/53c7,8xx.c
$
Yup. With the exception of Configure.help it's all essentially binary
stuff.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Rik van Riel <[EMAIL PROTECTED]>
Subject: Re: Kernel problem (PANIC)
Date: Tue, 13 Apr 1999 21:57:20 +0200
On Tue, 13 Apr 1999, Koh wrote:
> BUT during boot up, it STOP at mouting to root
> directory. The message is "(something)..... PANIC ...."
^^^^^^^^^^^
> and the system hang.
I have a hint for you: there's a good chance that
the (something) contains all the information we need
to help you solve your problem...
Too bad you snipped the useful part :(
Rik -- Open Source: you deserve to be in control of your data.
+-------------------------------------------------------------------+
| Le Reseau netwerksystemen BV: http://www.reseau.nl/ |
| Linux Memory Management site: http://humbolt.geo.uu.nl/Linux-MM/ |
| Nederlandse Linux documentatie: http://www.nl.linux.org/ |
+-------------------------------------------------------------------+
------------------------------
Subject: Re: SMP Linux, Any Catches?
From: Michael Meissner <[EMAIL PROTECTED]>
Date: 13 Apr 1999 17:03:08 -0400
"Clint Byrum" <[EMAIL PROTECTED]> writes:
> We have a system which we are porting to Linux from NT/HP-UX/AIX. All of the
> aforementioned handle Multiprocessing extremely well(ok, two of the
> aforementioned). Will Linux handle 200-300 user telnet/serial getty
> connections well with 2 or 4 processors(Xeon 450's) and a Hardware RAID? I
> would like to make sure so we can throw NT out the door. Currently we have
> to go with HP or IBM for anything higher than 100 users.
>
> Also, we are tied to RedHat for our database.
Note that you probably should upgrade from the RedHat 2.0.36 kernel (which BTW
does not have SMP support enabled in the binaries RedHat ships) to one of the
2.2.x kernels (2.2.5 is the latest release, and I think the latest Alan Cox
patch to 2.2.5 is 2.2.5-ac6) due to SMP being much better supported (2.0.x
systems only supported 2 processors IIRC, and did the old lock around the
kernel).
If you weren't tied to the x86 architecture, the Solaris porters have gotten
Linux to run on a 14 processor system (dunno how stable it is).
I recall that Ultrapenguin just announced an 8-way Xeon processor system for
sale.
--
Michael Meissner, Cygnus Solutions
174 Littleton Road #3-198
Westford, Massachusetts 01886
email: [EMAIL PROTECTED] fax: 978-692-4482
------------------------------
From: Carlos Vidal <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Insure++ questions.
Date: Thu, 08 Apr 1999 10:21:54 +0200
> exec(): 0509-036 Impossible to load the program applinet.so for due to the
> following reasons
> 0509-023 Symbole _Insight_stack_call in ksh undefined
> 0509-023 Symbole _Insight_call in ksh undefined
> .... more errors deleted ..
> 0509-023 Symbole _Insight_errorf in ksh undefined.
> 0509-026 System error : Impossible to execute a file with a bad format
> (sorry, I had to translate this message from french.)
It seems that either you are not linking with Insure
libraries or that you don't have the library installation
path in your LD_LIBRARY_PATH.
--
Carlos Vidal
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Dirk Lattermann)
Subject: Parallel port access using parport device
Date: Tue, 13 Apr 1999 19:08:39 +0200
Hello,
is it possible to access the parallel ports via the
parport device driver (the one accessed by the parallel
printer driver), rather than using directly the io-ports
(inb/outb)?
If yes, how is it done?
Thanks and bye,
Dirk Lattermann
------------------------------
From: "dave madden" <[EMAIL PROTECTED]>
Subject: Re: persistent heap design advice please
Date: 08 Apr 1999 11:06:15 -0700
In article <7eifqa$[EMAIL PROTECTED]> "Keith Morgan" <[EMAIL PROTECTED]>
writes:
=>I am interested in creating a persistent heap library and would appreciate
=>any hints or
=>suggestions on how to proceed. The 'persistent heap' would be a region of
=>virtual memory
=>backed by a file and could be expanded or contracted.
=>
=>In order to build my 'persistent heap' it seems like I need a fundamental
=>facility that isn't
=>provided by Linux. Please correct me if I'm wrong! It would be something
=>like a blend of
=>the mmap() and kernel virtual memory facilities. The facility (call it
=>phmap) would:
=>
=>-map virtual addresses to a user-specified file
=>-coordinate the expansion/contraction of the file and the virtual address
=>space
=>-provide ram cache of user-specified number of pages (cache itself is
=>nonpagable)
=>-provide load-on-demand of data from the file into the cache
=>-provide LRU 'paging' back to the file when cache full
I think mmap() will do most of what you want, except possibly for the
automatic expansion/contraction of the file. However, you've got a
huge amount of work to do before you'll need to worry about that.
Specifically, you have to consider what types of data you want to be
able to live in the heap. If it's simple data (basically, each datum
is independent and doesn't need to point to or otherwise reference any
other), then you're probably better off just leaving the information
in a file and letting the system's buffer cache speed things up for
you. If, OTOH, you're going to allow complex data structures
(anything that involves pointers) you've got some tough decisions to
make.
* You'll have to use offsets instead of pointers in all heap objects,
because processes may attach the persistent heap at different
addresses.
* You won't be able to store any C++ object that uses virtual
functions, RTTI, or (possibly) exceptions in the heap.
* You'll have to provide some locking mechanism so that multiple
processes don't step on each other when accessing the heap. This
will probably have to be done with semaphores rather than
pthread_mutex_t's.
* You'll have to decide what to do when you detect a broken object --
that is, one that's locked, but the process that locked it is gone.
Is the object still usable? If not, can you at least run its
destructor so that you clean up some of its resources? Is it safe
to just create a new object? What if some other process was waiting
to use the old one?
Error detection and recovery make for a really tough problem; I'm
trying to solve it adequately so several complementary processes can
use a shared memory segment. I currently believe that the best you
can do is to leak shared (or persistent-heap) memory slowly over
time. (If you can do better, it's only because the data structures
you're building are butt-simple, and maybe you don't need shared
memory at all.)
good luck,
d.
--
header address is anti-spamified. use caution when replying by
email to <[EMAIL PROTECTED]> because my real address
omits the hostname.
------------------------------
From: Rik van Riel <[EMAIL PROTECTED]>
Subject: Re: asynchronous disk I/O
Date: Tue, 13 Apr 1999 21:54:11 +0200
On Tue, 13 Apr 1999 [EMAIL PROTECTED] wrote:
> Can anyone confirm that Linux does not support asynchronous disk
> I/O? On AIX and Digital Unix we have system calls like
> lio_listio(), but I cannot find anything similar to that.
Linux 2.2 has this function. If you've been looking at
version 2.0 it's no wonder -- you're looking at 3 year
old code...
If you have a bit of time left, it's probably a good idea
to wait for SuSE 6.1 or Redhat 6.0...
Rik -- Open Source: you deserve to be in control of your data.
+-------------------------------------------------------------------+
| Le Reseau netwerksystemen BV: http://www.reseau.nl/ |
| Linux Memory Management site: http://humbolt.geo.uu.nl/Linux-MM/ |
| Nederlandse Linux documentatie: http://www.nl.linux.org/ |
+-------------------------------------------------------------------+
------------------------------
From: David Grothe <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: M-systems binary only drivers & GPL
Date: Tue, 13 Apr 1999 21:12:50 GMT
Alexander Viro wrote:
> To be serious, we already have tons of binary stuff in drivers/scsi/
> and IIRC that's where the largest files live. Let's see:
> $ cd /usr/src/linux
> $ du `find -size +200k`|sort -r
> 556 ./drivers/scsi/advansys.c
Can you clarify a bit for me? I looked at advansys.c and it seems to be 10,000
lines of actual C code with 1,000 lines of some initialized data embedded in it.
Can you elaborate on your point a bit?
Thanks,
Dave
------------------------------
Date: Tue, 13 Apr 1999 11:16:43 +0100
From: Lorenz Hahn <[EMAIL PROTECTED]>
Subject: Re: linux 2.2.5, SMP, device driver
Hi there,
many thanks to those who helped. As first, my problem is solved. I found
some hardware documentation in the web and so I was enabled to trace the
problem down.
Until then I didn't realized that these two accesses didn't just enabled
the interrupt but also cleared any pending interrupts. While the second
processor started the handling of the interrupt the first CPU cleared it.
The interrupt handler of the device driver couldn't recognize it any more.
On 12 Apr 1999, bill davidsen wrote:
> Lorenz Hahn <[EMAIL PROTECTED]> wrote:
>
> | At the first look a cache problem, but why does it occur only when two CPU's
> | are involved? Any known caveats?
>
> You got a great answer, I'll only note one more thought, when you built
> the kernel did you use the advanced clock stuff? You need that with SMP.
Do you mean 'Enhanced Real Time Clock Support'=CONFIG_RTC? Yes, it's enabled.
CU, Lorenz.
--
Lorenz Hahn email: [EMAIL PROTECTED]
SYSGO RTS GmbH, Carl-Zeiss-Str. 41 phone: +49 (0) 6131 9138-46
D-55129 Mainz / Germany fax: +49 (0) 6131 9138-10
PGP public key fingerprint: 5E 51 B2 DF DF E2 49 AD BD 7A FC 26 3F 19 58 25
------------------------------
From: [EMAIL PROTECTED] (Steve Summit)
Crossposted-To: comp.lang.c
Subject: Re: a problem with scanf
Date: 13 Apr 1999 15:37:39 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jack Klein) writes:
>On Mon, 12 Apr 1999 21:30:40 +0200, Francesc Oller
><[EMAIL PROTECTED]> wrote in comp.lang.c:
>> void main(void)
>> {
>> char c;
>> setvbuf(stdin,NULL,_IONBF,0);
>> tty_raw(0);
>> scanf("%c",&c);/*c=getchar();*/
>> tty_reset(0);
>> printf("c='%c'\n",c);
>> }
>>
>> where tty_raw puts the terminal in RAW mode and tty_reset
>> returns it to COOKED mode, makes me to have to press two chars
>> in order for scanf to get the first (i.e printf doesn't
>> execute until I press twice).
>>
>> However getchar works as expected (only one keyb press)
>> WHY?
>
> This question has nothing to do with the C language. In fact it stops
> being legal C when you typed "void main(void)"...
Nevertheless, the post clearly has *something* to do with the
C language.
> A bigger issue is that there are no functions named setvbuf(),
> tty_raw() or tty_reset() in the C language. Please keep your Linux
> specific questions in the Linux groups and out of comp.lang.c.
The actual question here may not be so Linux specific.
> But if you want to know why scanf() is evil and should be avoided in
> almost all situations, especially for live user input, see the
> comp.lang.c FAQ.
Which doesn't quite answer the question, although 12.17 and 12.18
are closely related.
In general, scanf has to read ahead a bit to find the *end* of
the sequence it's trying to match with a %-specifier. (This fact
is, of course, the source of many of scanf's quirks and foibles.)
I'm not sure why scanf should be reading ahead on %c, and in fact
on the first system I tried it it didn't (that is, Francesc's
code worked "as expected", after replacing tty_raw(0) with
system("stty raw") ). But when I tried it on a nearby Linux
system, it did in fact wait for a second character.
This may indicate a slight bug in the GNU/Linux libc, although
the workaround is exquisitely simple in this case: just use
getchar, which is what you probably wanted to use all along.
(In general, scanf %c is a lousy substitute for getchar.)
Steve Summit
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: M-systems binary only drivers & GPL
Date: 13 Apr 1999 19:26:45 -0400
In article <[EMAIL PROTECTED]>, David Grothe <[EMAIL PROTECTED]> wrote:
>Alexander Viro wrote:
>
>> To be serious, we already have tons of binary stuff in drivers/scsi/
>> and IIRC that's where the largest files live. Let's see:
>> $ cd /usr/src/linux
>> $ du `find -size +200k`|sort -r
>> 556 ./drivers/scsi/advansys.c
>
>Can you clarify a bit for me? I looked at advansys.c and it seems to be 10,000
>lines of actual C code with 1,000 lines of some initialized data embedded in it.
>Can you elaborate on your point a bit?
Yes. Said data is code. Binary. With no source. Intended not for x86 but for
the controller. It may be considered as huge initialization sequence, but it
is real, honest code. See also drivers/net/acenic_firmware.h - 388K of
hexadecimal stuff. And drivers/net/dgrs_firmware.c - 360K of the same stuff
(119K of binary). AFAICS firmware is considered as exception.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: PROC-fs, Need to make it CHARGEBEL
Date: 13 Apr 1999 17:45:16 +0200
[EMAIL PROTECTED] writes:
> Hello,
>
> I need statistics from the kernel about how many jiffies a process has
> used when it's done.
Just use "time process" in your shell.
2.2 also has BSD style process accounting when you compile it in,
then the kernel is able to automatically write an accounting
record for every finished process to a file. See include/linux/acct.h
for the information it contains.
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Crossposted-To: comp.emulators.ms-windows.wine
Subject: Re: Is use of WINE acceptable for a short-term implementation of ThinkPad
Modem?
Date: 13 Apr 1999 20:41:37 +0200
[EMAIL PROTECTED] (Dionyshs Papadopoulos) writes:
> >[BTW Linux 2.2 has a "soundmodem" driver that can do 9600baud over a
> > soundblaster]
> Could you tell me more info about soundmodem?
> (or tell me where to look for?)
Standard kernel source:
drivers/net/hamradio/soundmodem/*
Documentation/networking/soundmodem.txt
It is only half duplex, FSK and aimed at HAM radio operation.
Also you need enough CPU power.
It is useful for a really lowcost CB packet radio connection.
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: Francesc Oller <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: a problem with scanf
Date: Tue, 13 Apr 1999 20:18:58 +0200
Reply-To: [EMAIL PROTECTED]
Jack Klein wrote:
>
> On Mon, 12 Apr 1999 21:30:40 +0200, Francesc Oller
> <[EMAIL PROTECTED]> wrote in comp.lang.c:
>
> > executing the following code in LINUX:
> >
> > ...
> > void main(void)
> > {
> > char c;
> > setvbuf(stdin,NULL,_IONBF,0);
> > tty_raw(0);
> > scanf("%c",&c);/*c=getchar();*/
> > tty_reset(0);
> > printf("c='%c'\n",c);
> > }
> >
> > where tty_raw puts the terminal in RAW mode and tty_reset
> > returns it to COOKED mode, makes me to have to press two chars
> > in order for scanf to get the first (i.e printf doesn't
> > execute until I press twice).
> >
> > However getchar works as expected (only one keyb press)
> > WHY?
> >
> > Francesc Oller
>
> <Jack>
> A bigger issue is that there are no functions named setvbuf(),
> tty_raw() or tty_reset() in the C language. Please keep your Linux
> specific questions in the Linux groups and out of comp.lang.c.
I wasn't trying to say that tty_raw/tty_reset are standard C.
I've written them myself but thought they were irrelevant to the
problem.
BTW, I'm interested in C, no matter which OS ;-)
> But if you want to know why scanf() is evil and should be avoided in
> almost all situations, especially for live user input, see the
> comp.lang.c FAQ.
Rest assured. If I ever ask a question in a newsgroup, is because
I've already done my homework.
In order to reach some productive conclusions, I'm commenting a
feature (bug?) of scanf (perhaps related to the former) not
directly related to an specific OS:
int i;scanf("%d%*c",&i);
user input: 345\n
I understand that scanf should parse 345 (i==345) and eat \n.
In some implementations it's just as this. In another, scanf keeps
reading.
According to P.J. Plauger (>
http://www.dinkumware.com/htm_cpl/lib_scan.html
) scanf finishes when:
1.- it reaches the terminating null in the format string
2.- it cannot obtain additional input characters to scan (input failure)
3.- a conversion fails (matching failure)
Then, scanf should return,shouldn't it? (case 1)
thanks for your time
Francesc Oller
------------------------------
** 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
******************************
