Linux-Development-Sys Digest #284, Volume #8 Thu, 16 Nov 00 15:13:15 EST
Contents:
uaccess question (Arne Driescher)
Re: Free Memory available??? (Frederic S. Parain)
Packet ordering (Ed Hudson)
PCI device I/O and user space buffers ("Tom")
Video-in for C&T 69000 with an attached SAA7111 (Sven Fischer)
Re: PCI device I/O and user space buffers (Arne Driescher)
More than 26 SCSI disks ([EMAIL PROTECTED])
Re: lilo and minimize linux ("Daniel Ivarsson")
Re: make[3]: *** [ip_masq.o] Error 1 (Jamie Walker)
Re: make[3]: *** [ip_masq.o] Error 1 (Paul Kimoto)
Re: raw packet socket; how to retransmit ("Vadim Model")
DEC DE-500 Drivers ("kevin")
Re: Was: Software RAID (bill davidsen)
Re: raw packet socket; how to retransmit (Andi Kleen)
Re: raw packet socket; how to retransmit (Grant Edwards)
Re: uaccess question (Andi Kleen)
Re: Segmentation faults with struct hostent & char ** ("Christoper McClan")
Pointers, arrays and in_addr! ("Christoper McClan")
Re: linux API (Erik Hensema)
----------------------------------------------------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Subject: uaccess question
Date: Thu, 16 Nov 2000 17:33:14 +0100
Hi,
2 short questions concerning the acces from a device driver to user
space:
1) I try to pass a struct by ioctl calls from user space to a device
driver.
#define MAX_MICROCODE_SIZE_PER_PAGE 0x1000
typedef enum{Bank0, Bank1} bank_enum;
typedef struct{
bank_enum bank; // bank used for download
unsigned int length; // number of bytes to write to the bank
unsigned char code[MAX_MICROCODE_SIZE_PER_PAGE]; // array with values
} micro_code_struct;
static int
ioctl_download_microcode(micro_code_struct * addr)
{
unsigned char old_run_control_register;
unsigned int i;
int err;
micro_code_struct micro_code;
if (addr && (err = verify_area(VERIFY_READ, addr,
sizeof(micro_code_struct)))){
printk(KERN_ERR "fub:verify_area microcode_download failed\n");
return err;
} else {
printk(KERN_ERR "ioctl_set_da called\n");
}
This works perfect as shown here but verify_area fails if
MAX_MICROCODE_SIZE_PER_PAGE is larger.
I need 0x4000 bytes to transfer to the driver. I can think of many work
arounds
but would like to know _why_ there is a limit to this. It is obviously
not PAGE_SIZE and
I did not understand much of what the macros in uaccss.h do.
2) In nearly the same code (an other ioctl call) I forgot to use
copy_from_user
to get the date from user space. Instead I used addr directly and it
worked perfectly
(e.g. addr->some_value).
This is certainly a nice feature but until now I thought that user and
kernel space
use different address spaces. How can you explain this feature? (I don't
want to use it
because it is certainly a good way to write a non-portable driver, but
again I would like
to understand the _why_ and _how_.)
-Arne
P.S. Linux-Kernel: 2.2.14-i386
------------------------------
From: [EMAIL PROTECTED] (Frederic S. Parain)
Subject: Re: Free Memory available???
Date: 16 Nov 2000 17:31:35 +0100
"Arint�" <[EMAIL PROTECTED]> writes:
> Is there a function call in linux to get the amount memory available?
> How about a system call? This is for a c project.
Why don't you just open and parse the file /proc/meminfo?
--
Frederic S. PARAIN - PhD Student - Projet SOLIDOR
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
T�l: +33 (0) 2 99 84 75 34, e-mail: [EMAIL PROTECTED]
"Everything should be as simple as possible, but not simpler"
------------------------------
From: Ed Hudson <[EMAIL PROTECTED]>
Subject: Packet ordering
Date: Thu, 16 Nov 2000 12:01:24 -0500
We have noticed that when a fragmented ping is sent to a linux system,
it is returned in reverse order (ie last fragment first). Is there a
way to force linux to return the packets in the order received?
Thanks
Ed
------------------------------
From: "Tom" <[EMAIL PROTECTED]>
Crossposted-To: fa.linux.kernel
Subject: PCI device I/O and user space buffers
Date: Thu, 16 Nov 2000 17:11:37 GMT
Hi,
Sorry for such a dumb question. Kernel/module newbie.
It is my understanding from RTFM's, news postings, etc., that a device
driver can not directly copy data from a user space buffer to PCI I/O space
using the write(b,w,l), read(b,w,l), memcpy_toio, and memcpy_fromio function
calls.
For example, if a module/driver needed to move data from a user space buffer
to a PCI device (no DMA), the module/driver must allocate a kernel space
buffer, do a copy_from_user to the kernel space buffer, and then do
write(b,w,l)'s, memcpy_toio to the PCI space using the kernel space buffer
rather than simply using the user space buffer address in the
write(b,w,l)/memcpy_toio calls.
Is my understanding correct?
TIA,
Tom Anwyll
------------------------------
From: Sven Fischer <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.embedded,comp.os.linux.x
Subject: Video-in for C&T 69000 with an attached SAA7111
Date: Thu, 16 Nov 2000 18:19:36 +0100
Reply-To: [EMAIL PROTECTED]
Hello all,
I have an embedded PC-system with an Chips&Techn. 69000 graphics chip,
where a SAA7111 frame grabber is connected. Now I wonder if there is any
possibility to get the video picture unter X.
I know that there is a driver for the 7111, but the connection to the 69000
is obviously not supported. Does anyone have experience with this
combination anyway?
Thanx a lot for your support,
Greetings, Sven
------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Crossposted-To: fa.linux.kernel
Subject: Re: PCI device I/O and user space buffers
Date: Thu, 16 Nov 2000 18:44:25 +0100
Tom wrote:
>
> Hi,
>
> Sorry for such a dumb question. Kernel/module newbie.
>
> It is my understanding from RTFM's, news postings, etc., that a device
> driver can not directly copy data from a user space buffer to PCI I/O space
> using the write(b,w,l), read(b,w,l), memcpy_toio, and memcpy_fromio function
> calls.
>
> For example, if a module/driver needed to move data from a user space buffer
> to a PCI device (no DMA), the module/driver must allocate a kernel space
> buffer, do a copy_from_user to the kernel space buffer, and then do
> write(b,w,l)'s, memcpy_toio to the PCI space using the kernel space buffer
> rather than simply using the user space buffer address in the
> write(b,w,l)/memcpy_toio calls.
>
> Is my understanding correct?
>
> TIA,
> Tom Anwyll
Yes and no :-)
On the i386 write and read expand to "normal" memory operations and any
instruction accessing
the mem can be used. However, this is non-portable!
If your only concern for i/o is to avoid the copy operation then use
mmap
to map the pci i/o directly to user space.
-Arne
------------------------------
From: [EMAIL PROTECTED]
Subject: More than 26 SCSI disks
Date: Thu, 16 Nov 2000 17:35:50 GMT
Hi,
is there somebody who managed to have more than 26 SCSI disks in a Linux
box ?
Here's my configuration:
Pentium Pro 200
1GB RAM
Adaptec 3940 with 4+1 disks
Dual channel FWD controller with NCR 53c875 chipset with 15+10 disks
SUSE 6.4 with kernel 2.2.14
I installed the necessary /dev/sdXY device files (major 65, minor 0-255,
sdq - sdaf15)
I tried the ncr53c8xx module and the sym53c8xx module.
I know the disks are there because the driver sees them when it scans
the scsi bus. It even assigns the correct device name. But the devices
sdaa - sdad are not registered in the kernel. Any idea ?
Please answer to [EMAIL PROTECTED] as I don't always have the
time to check the news. Thanks.
Cheers
Bernhard
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Daniel Ivarsson" <[EMAIL PROTECTED]>
Subject: Re: lilo and minimize linux
Crossposted-To: comp.os.linux.setup
Date: Thu, 16 Nov 2000 18:07:48 GMT
In article <[EMAIL PROTECTED]>, "Hung P. Tran"
<[EMAIL PROTECTED]> wrote:
> I am trying to fit linux onto a 60 MB harddrive. Obviously, the drive is
> too small for a standard linux installation.
>
> My first question is how to install lilo on the drive and make it boot
> linux. I tried to partition the drive using: fdisk /dev/hdc (the drive
> is connected as secondary IDE master). I just assign a single partition
> #1 (hdc1). Then I make the file system using mkfs, and then mount the
> harddrive as /mnt/d. Then I copy a few file from my original RedHat 6.1
> over. Here is an output from "ls -l /mnt/d"
>
> total 927
> -rw-r--r-- 1 root root 4568 Oct 17 14:33 boot.b
> -rw-r--r-- 1 root root 285018 Oct 17 16:19 initrd.img
> -rw-r--r-- 1 root root 250 Oct 17 17:17 lilo.conf
> drwxr-xr-x 2 root root 12288 Oct 17 14:30 lost+found
> -rw------- 1 root root 13312 Oct 17 16:21 map
> -rw-r--r-- 1 root root 622784 Oct 17 16:18 vmlinuz
>
> The new modified lilo.config is as followed:
>
> boot=/dev/hdc map=/mnt/d/map install=/mnt/d/boot.b prompt timeout=50
> default=linux
>
> image=/mnt/d/vmlinuz
> label=linux initrd=/mnt/d/initrd.img read-only root=/dev/hdc1
>
> I then run: /sbin/lilo -C /mnt/d/lilo.conf
>
> I then reboot the system and configure the BIOS to boot from the
> secondary master IDE (it can boot up fine from a secondary master IDE
> with DOS). However, I only get a bunch of 01 01 01 ... on the screen.
>
> What did I do wrong ? What am I missing ?
>
> I apologize for the long email. Any advice is appreciated.
>
> Thank you in advance,
>
> hung
>
>
>
>
An idea is to remove all occurances of "/mnt/d" in you lilo.conf file (on
/mnt/d) because this drive will be mounted as your rott device, right?
An then you'll want to do a "lilo -v -t -C /mnt/d/lilo.conf" to see if
LILO really updates the MBR on you /dev/hdc I everything's alright then
you can do a "lilo -C /mnt/d/lilo.con" and test if it works...
NOTE: This is how I think that it might work, I've never done it... (Do
NOT trust me 100% :))
Cheers...
--
Daniel Ivarsson <[EMAIL PROTECTED]> WWW: N/A ICQ: 23155870 Tel: +46
(0)704 818702
------------------------------
From: Jamie Walker <[EMAIL PROTECTED]>
Subject: Re: make[3]: *** [ip_masq.o] Error 1
Date: Thu, 16 Nov 2000 17:18:17 +0000
In article <8uvm36$fnc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes
>I'm trying to build a kernel on a 486-DX2 using source from kernel-
>source-2.2.16-22.i386.rpm. The distribution was from RedHat 7.0.
>The gcc version is 2.96.
I don't think you will be able to compile the kernel with the version of
GCC shipped with Redhat 7.0.
Try installing the 'kgcc' package from the and use it to compile the
kernel.
HTH,
--
Jamie Walker "While there are no known bugs in it, it might
[EMAIL PROTECTED] destroy your filesystems, eat your data and
http://www.sagaxis.co.uk/ start World War III. You have been warned."
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: make[3]: *** [ip_masq.o] Error 1
Date: 16 Nov 2000 13:06:26 -0500
Reply-To: [EMAIL PROTECTED]
In article <8uvm36$fnc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I'm trying to build a kernel on a 486-DX2 using source from kernel-
> source-2.2.16-22.i386.rpm. The distribution was from RedHat 7.0.
> The gcc version is 2.96.
2.2.* kernels are not coded to work with (the never-released) gcc-2.96
(and its successors). Instead, you should use egcs-1.1.*, which Red Hat
provides in the "kgcc" package. (Also allowed are gcc-2.7.2.3 and
gcc-2.95.*.)
--
Paul Kimoto
This message was originally posted on Usenet in plain text. Any images,
hyperlinks, or the like shown here have been added without my consent,
and may be a violation of international copyright law.
------------------------------
From: "Vadim Model" <[EMAIL PROTECTED]>
Subject: Re: raw packet socket; how to retransmit
Date: Thu, 16 Nov 2000 21:52:09 +0300
I understand all your arguments and believe me I'm not a newbee in network
programming.
If you have time, please look into any of Ethernet driver. There you will be
able to see that certain device registers give you an indication of TX
status. I want to know if that status is OK or not. Nothing more.
>There are many ways in which an ACK can get lost. Most are not
>detectible. Notifying the user of one but not all of them is
>useless.
Can not agree on this. Some information which you call "useless" may help a
lot detecting source of problem. And if you hide information it makes
troubleshooting process much more difficult (have you ever got a call from
customer saying "nothing works"?). This is why devices usually have status
registers (see above). This is why I have to emulate status register of that
Ethernet controller for which I provide software emulation.
>Nobody cares whether a frame is transmitted or not. People
Device driver does. At least in OpenVMS, and in Linux, and in any other
operating system.
>Since there is no difference between a frame being transmitted
>and not received and a frame not being transmitted, then you
The difference is the status provided by Ethernet controller on TX_DONE
interrupt.
>anything. ACKs could still get lost even thought he Ethernet
>board thinks they've been transmitted. Your protocol has to
>deal with that.
Totally agree. It has to, but surely it does not. Anyway I do not care about
that protocol. I did not design it. But I just want to distinguish two
situations: packet is not sent because cable is removed from TP socket or
broken; or packet is sent but get lost somewhere in hubs. In addition it
would be nice to get to know how many collisions had been detected before
packet is sent.
Regards,
Vadim
>
>--
>Grant Edwards grante Yow! Look DEEP into the
> at OPENINGS!! Do you see
any
> visi.com ELVES or EDSELS... or a
> HIGHBALL??...
------------------------------
From: "kevin" <[EMAIL PROTECTED]>
Subject: DEC DE-500 Drivers
Date: Thu, 16 Nov 2000 18:51:21 GMT
I'm running Slackware 3.4 and I'm looking for drivers for a DEC DE500 10/100
Nic.
If anyone knows of where I can find one I'd appreciate it :)
thanks
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To:
comp.os.linux.hardware,alt.linux,comp.os.linux.misc,comp.os.linux.hardware
Subject: Re: Was: Software RAID
Date: 16 Nov 2000 18:56:36 GMT
In article <[EMAIL PROTECTED]>,
U. Siegel <[EMAIL PROTECTED]> wrote:
| The filesystem was created by the command:
| mke2fs -b 4096 -R stride=8 /dev/md0
I've been running software raid since 2.2.6 or so, but I never tried
the RAID stuff in mke2fs (don't believe it was there). So to isolate the
problem to RAID code or e2fs code, you might try leaving the -R out and
see if it suddenly works.
Actually, I never ran with a spare, either, I just replace a failed
drive and "hotadd" the drive back in, so you are in some uncharted water
there, as far as I can help.
--
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: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: raw packet socket; how to retransmit
Date: 16 Nov 2000 19:59:25 +0100
"Vadim Model" <[EMAIL PROTECTED]> writes:
>
> >Watching interface error counters is not sufficient, because it does not
> >guarantee that the packet reached the application layer at the other end
> >(remember IP/Ethernet packets are allowed to be dropped when convenient,
> e.g.
> >when the host is temporarily out of memory)
>
>
> I do not talk about IP. On hardware level I can check if the frame is sent
> or not. So I want to be able to detect the same from user level application.
No you can't. That was the whole point. The linux ethernet layer honours
the IP internetworking principle that states "packets can be dropped anywhere
when convenient" (mostly in low memory situations). Also standard 802.2
ethernet does not even have a way to do guaranteed delivery (there are
IEEE 802.x protocols for reliably delivery, but they're not directly
accessible via Linux packet sockets except when you implement them yourself)
For an reliable protocol you need at least L3 acknowledgements.
-Andi
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: raw packet socket; how to retransmit
Date: Thu, 16 Nov 2000 19:20:29 GMT
In article <8v19k0$vfc$[EMAIL PROTECTED]>, Vadim Model wrote:
>If you have time, please look into any of Ethernet driver.
>There you will be able to see that certain device registers
>give you an indication of TX status. I want to know if that
>status is OK or not. Nothing more.
Agreed -- all of the Ethernet controllers I've seen made that
information available. The problem is that it's extremely
difficult (with current stack/driver designs) to get that
status info back up to the application. At the point where the
Tx failure status is known, the driver typically doesn't know
to whom the failed packet belongs.
[...]
>>Since there is no difference between a frame being transmitted
>>and not received and a frame not being transmitted, then you
>
>The difference is the status provided by Ethernet controller on
>TX_DONE interrupt.
Right, but in either case, an application has to do the same
thing. If the action taken by the app is the same for two
cases, then it can be argued that it's not required that the
appliction know which case occured, only that one of them
occured.
>>anything. ACKs could still get lost even thought he Ethernet
>>board thinks they've been transmitted. Your protocol has to
>>deal with that.
>Totally agree. It has to, but surely it does not.
That's too bad.
>Anyway I do not care about that protocol. I did not design it.
>But I just want to distinguish two situations: packet is not
>sent because cable is removed from TP socket or broken; or
>packet is sent but get lost somewhere in hubs.
That information could, in theory, be passed back up to the
application, but it's a pretty nasty problem. The send() or
write() syscall returns as soon as the information has been
queued for transmit. At some point later in time, the Ethernet
driver notices that a transmit failed. Now there are two
problems:
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.
>In addition it would be nice to get to know how many collisions
>had been detected before packet is sent.
If you just want to query the state of the interface, that's a
considerably easier problem. Doing a cat on /proc/dev/net
shows fields for both collisions and carrier-faults (among
other things).
I don't know if there is a more direct API to get that info,
but open() and read() on /proc/net/dev/ should get you that
info.
--
Grant Edwards grante Yow! Bo Derek ruined
at my life!
visi.com
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: uaccess question
Date: 16 Nov 2000 20:19:46 +0100
Arne Driescher <[EMAIL PROTECTED]> writes:
> Hi,
>
> 2 short questions concerning the acces from a device driver to user
> space:
>
> 1) I try to pass a struct by ioctl calls from user space to a device
> driver.
>
> #define MAX_MICROCODE_SIZE_PER_PAGE 0x1000
> typedef enum{Bank0, Bank1} bank_enum;
>
> typedef struct{
> bank_enum bank; // bank used for download
> unsigned int length; // number of bytes to write to the bank
> unsigned char code[MAX_MICROCODE_SIZE_PER_PAGE]; // array with values
> } micro_code_struct;
>
> static int
> ioctl_download_microcode(micro_code_struct * addr)
> {
> unsigned char old_run_control_register;
> unsigned int i;
> int err;
> micro_code_struct micro_code;
>
> if (addr && (err = verify_area(VERIFY_READ, addr,
> sizeof(micro_code_struct)))){
> printk(KERN_ERR "fub:verify_area microcode_download failed\n");
> return err;
> } else {
> printk(KERN_ERR "ioctl_set_da called\n");
> }
>
> This works perfect as shown here but verify_area fails if
> MAX_MICROCODE_SIZE_PER_PAGE is larger.
> I need 0x4000 bytes to transfer to the driver. I can think of many work
> arounds
> but would like to know _why_ there is a limit to this. It is obviously
> not PAGE_SIZE and
> I did not understand much of what the macros in uaccss.h do.
In 2.2 verify_area (ignoring a corner case that only happens on early
steppings of the original 386) only checks if the address is in
user space (so that a malicious user cannot pass a kernel address)
It is basically if (ptr+size < __PAGE_OFFSET) return -EFAULT; done in lots
of assembly magic to avoid overflows and make it as fast as possible.
In 2.2 code you should not use verify_area anymore but only check the return
value of the *_user() call directly, because it is the one that checks the
page tables by handling the exceptions properly.
When you pass it a correct address it should not fail though, so you're
probably passing a wrong one.
>
> 2) In nearly the same code (an other ioctl call) I forgot to use
> copy_from_user
> to get the date from user space. Instead I used addr directly and it
> worked perfectly
> (e.g. addr->some_value).
> This is certainly a nice feature but until now I thought that user and
> kernel space
> use different address spaces. How can you explain this feature? (I don't
> want to use it
> because it is certainly a good way to write a non-portable driver, but
> again I would like
> to understand the _why_ and _how_.)
They do not on the current i386 port, but when the user pages happens
to be swapped out you'll get a nice crash. It also does not work
on most other linux ports. So better do not do it.
-Andi
------------------------------
From: "Christoper McClan" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: Re: Segmentation faults with struct hostent & char **
Date: Thu, 16 Nov 2000 19:51:51 +0000
Cheers,
I've since discovered "malloc". Can't believe you have to assign memory yourself!
Christopher.
In article <8v07c7$[EMAIL PROTECTED]>, "Slawek Grajewski"
<[EMAIL PROTECTED]> wrote:
> This should work.
>
> int main()
> {
> char **alias_list; struct hostent *host_name;
>
> // in order for host_name->h_name assignment below to work you shoud
> declare
> // host_name in the following way:
> // struct hostent host_name; // NO STAR
>
>
> #define NOF_ALIASES 1
> *alias_list = malloc (NOF_ALIASES * sizeof(aliast_list[0]));
> assert(*alias_list);
>
> //host_name->h_name="mymachine.mydomain.net";
> alias_list[1]="hello";
> }
>
>
>
> Christoper McClan wrote in message
> <8uv3vj$gq8$[EMAIL PROTECTED]>...
>>Look at the following small piece of code :
>>---------------------------
>>
>>#include <sys/types.h>
>>#include <sys/socket.h>
>>#include <stdio.h>
>>#include <netinet/in.h>
>>#include <arpa/inet.h>
>>#include <arpa/nameser.h>
>>#include <unistd.h>
>>#include <string.h>
>>#include <netdb.h>
>>
>>int main()
>>{
>> char **alias_list; struct hostent *host_name;
>> //host_name->h_name="mymachine.mydomain.net";
>> alias_list[1]="hello";
>>}
>>----------------------------------
>>This will compile & run fine. If however, you remove the comment from
>>the
>>"host_name" line, it will compile, but when executed will segmentation
> fault!?
>>
>>I've noticed this quie a bit, where you have to frig around working out
> when
>>and where you declare variables otherwise sometimes g++ (2.95.3)
>>compiled programs can die.
>>
>>Any help would be much appreciated!
>>
>>
>>Christopher.
>
>
------------------------------
From: "Christoper McClan" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: Pointers, arrays and in_addr!
Date: Thu, 16 Nov 2000 19:56:12 +0000
A small snipet of code :
#include <all relevant headers>
int main (int argc, char **argv)
{
struct in_addr ip1;
char **addr_list;
char *A;
addr_list = (char **)malloc(1024);
ip1 = *((struct in_addr *)malloc(1024));
inet_aton("192.168.1.1",&ip1);
addr_list[0]=(char *)&ip1;
inet_aton("192.168.1.5",&ip1);
addr_list[1]=(char *)&ip1;
printf("addr_list[0] : %s\n",inet_ntoa(*(struct in_addr *)addr_list[0]));
printf("addr_list[1] : %s\n",inet_ntoa(*(struct in_addr *)addr_list[1]));
}
The output is :
addr_list[0] : 192.168.1.5
addr_list[1] : 192.168.1.5
I'm not briliant with pointers and referencing etc, does anyone know of a good
resource for me to look them up?
Obviously I want to copy the IP addresses into the addr_list array rather than
copy a pointer to a in_addr structure (which is what I think is going on!?)
Fairly inexperienced at all this!
Thanks,
Christopher.
------------------------------
From: [EMAIL PROTECTED] (Erik Hensema)
Subject: Re: linux API
Date: Thu, 16 Nov 2000 16:45:55 +0100
Reply-To: [EMAIL PROTECTED]
Vikash K Agarwal ([EMAIL PROTECTED]) wrote:
>I am new to Linux, basically coming from DOS/WIN background, so i may sound
>silly ...
>Just like there were interrupts in DOS and API in Windows, what is the
>corresponding in the Linux OS??
Standard C-library calls. You are offcourse able to do direct systemcalls
to the kernel, but you'd better do it through the C library.
>Where can I find the documentation?
There are many, many books on Unix systems programming. Also, you can
consult the online manual pages, sections 2 and 3.
>Any good books on the subject??
>lets say i want to access a file using a Linux OS call, how do i do it
>using a Linux C compiler like GCC???
Files are accessed through the usual open(), read(), write() and close()
calls, or the fopen(), fprintf(), fscanf and fclose() calls.
>How do i program for the linux GUI, probably referred to as the X-Windows
>system??
You usually use a toolkit like Qt (for KDE development), GTK (for Gnome
development), Motif, Athena, Tk and countless others.
--
Erik Hensema ([EMAIL PROTECTED])
Registered Linux user #38371 -- http://counter.li.org
------------------------------
** 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
******************************
