Linux-Development-Sys Digest #988, Volume #7 Fri, 30 Jun 00 15:13:11 EDT
Contents:
put_user() ("Gordon Morison")
How I modify /etc/shadow? (Maximiliano Bonfiglio)
Re: put_user() (Mathias Waack)
Re: problem with makefile??? (newbie?) (Anita Hsiung)
Re: Good Basic compiler for linux? (Johan Kullstam)
Re: compiling 2.4-test2 kernel problem (John Gluck)
Re: Confirm this bug: CodeWarrior does not support spaces in paths? (John Gluck)
Re: MBR (John Gluck)
Re: Serial comms in C/C++/probably anything! (Jem)
making a boot/root disk- >libraries too big!! (Jerome Corre)
help: how to exhange data between user and kernel ("Duke Lee")
----------------------------------------------------------------------------
From: "Gordon Morison" <[EMAIL PROTECTED]>
Subject: put_user()
Date: Fri, 30 Jun 2000 14:27:19 +0100
Hello there
Can someone explain to me how the put_user() function works. I know that it
takes a variable from kernel space and makes it availible in user space but
I am unsure how to tie the two together. Is it enough, to name the variable
the same in a user space program, that it is named in the kernel space
program?
Thanks in advance
Gordon Morison
------------------------------
From: Maximiliano Bonfiglio <[EMAIL PROTECTED]>
Subject: How I modify /etc/shadow?
Date: Fri, 30 Jun 2000 15:18:48 +0200
Hi, folks
Who knows to say like makes itself to me from one program C of linux
changing the structure of an existing customer in the rows /etc/shadow?
Use getspnam in order to visualize the structure, but then as I modify
it?
Thanks
--
Maximiliano Bonfiglio
mailto:[EMAIL PROTECTED]
FLEXTEL S.p.A.
http://www.flextel.it
Corso Vercelli 328
IVREA 10015 TO Italy
tel 39-125-235319
fax 39-125-252067
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: put_user()
Date: 30 Jun 2000 15:20:59 +0200
"Gordon Morison" <[EMAIL PROTECTED]> writes:
> Can someone explain to me how the put_user() function works. I know
> that it takes a variable from kernel space and makes it availible in
> user space but I am unsure how to tie the two together. Is it enough,
> to name the variable the same in a user space program, that it is
> named in the kernel space program?
Of course not. put_user takes 2 arguments, first is the value and second
is a pointer into the user space. The latter is the position where the
user space program expects the result.
Common use is the ioctl method:
static int ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg)
{
// some checks
switch (cmd) {
case FIRST_CASE:
put_user_ret(42, (int*)arg, -EFAULT);
break;
...
}
(put_user_ret does the same as put_user - additionally it checks the result
and returns the error code if put_user failed)
The userspace program looks like
int val;
int fd;
fd = open("<my device file",O_RDONLY);
ioctl(fd,FIRST_CASE,&val);
assert(val == 42);
Hope I'm right and helpful
Mathias
------------------------------
From: Anita Hsiung <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc.help
Subject: Re: problem with makefile??? (newbie?)
Date: Thu, 29 Jun 2000 14:16:32 -0700
Jeff D. Hamann wrote:
>
> had to redit the makefile using gnotepad (emacs didn't seem to want to add
> the tab in there, or at least I didn't know hot to use it correctly to edit
> the makefile so that it would insert the tabs in there) And why was the
> tabbing different when i put a txt extension on the makefile? Regardless,
> it's working fine know, but I would like to be able to use emacs to generate
> the make and edit the c code.
Don't call the file "makefile.txt". That may change the mode
and do weird things to the <TAB> character. Emacs should work
just fine, though.
-- Anita --
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
* Anita Hsiung Lockheed Martin Space Systems *
* Systems Engineer Sunnyvale, California USA *
* [EMAIL PROTECTED] 408-756-3073 *
* *
* 500 BC: Supreme excellence consists in breaking the enemy's *
* resistance without fighting. -- Sun Tzu *
* *
* June 10, 1999 AD: B - A - N - G !!! *
* August 2, 1999 AD: BACK - 2 - BACK *
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: Good Basic compiler for linux?
Date: 30 Jun 2000 09:53:47 -0400
"Larry Ebbitt " <[EMAIL PROTECTED]> writes:
> On Tue, 27 Jun 2000 21:38:31 +0100, AndyD wrote:
>
> >A large number of people make a living programming in a variety of BASIC`s
> >and I for one would like to see a modern implementation of the language on
> >LINUX.
>
> I doubt that anyone over 14 would use it except that Billzebub likes it
> so Microflaccid pushes it. Don't forget what the "B" stands for.
oh come on. basic is actually a good language for some things. it's
simple and it's interactive. it's great for whipping off 10-20 line
proof of concept type programs. you know, crap like
10 x = 3
20 print x
30 x = x + 1
40 goto 20
basic doesn't scale well for anything serious, but that's ok sometimes.
however, visual basic is not basic.
--
johan kullstam l72t00052
------------------------------
From: John Gluck <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel,alt.os.linux
Subject: Re: compiling 2.4-test2 kernel problem
Date: Fri, 30 Jun 2000 10:12:24 -0400
Morten Liljeberg wrote:
> John Gluck <[EMAIL PROTECTED]> wrote:
> > gcc: Internal compiler error: program cc1 got fatal signal 11
> > gcc: Internal compiler error: program cc1 got fatal signal 11
>
> Try to look at http://www.bitwizard.nl/sig11
Try looking at the problem before making that me-too suggestion that's
been around for at least 5 years.
This was a trick question. Remember it has been possible to compile
anything and everything with this machine without incident.
The only problems occured when actually running the 2.4 kernel that was
compiled on the same machine under an earlier kernel version.
Assuming that every sig11 is a hardware problem is very limited
thinking.
The problem was actually a kernel bug(s) . They were fixed by applying
patches.
Everything works normally now on 2.4 ...
--
John Gluck (Passport Kernel Design Group)
(613) 765-8392 ESN 395-8392
Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.
------------------------------
From: John Gluck <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Confirm this bug: CodeWarrior does not support spaces in paths?
Date: Fri, 30 Jun 2000 10:19:30 -0400
Nate Eldredge wrote:
> John Gluck <[EMAIL PROTECTED]> writes:
>
> > > Should I mandate 8.3 filenames, in all caps? Hey, no "reasonable"
> > > developer uses long filenames, or mixed case..
> >
> > No there are very few operating systems in current use that require
> > that. I think the only ones that used to use that were on 8 bit
> > micros. Things like CP/M 80 Anyway, that was in the days when 64K of
> > RAM was huge and a floppy disk was 8 inches storing the inrcedible
> > quantity of 128K bytes of data. But I think we've left that century
> > and are adapting to the new freedom afforded by megabytes of RAM and
> > gigabytes of disk storage not to mention 32 bit and even 64 bit
> > computers.
>
> Hello? MS-DOS? It certainly ran on things far beyond 8-bit micros
> (it runs fine on my K6-3) and it isn't completely dead yet.
Let me point out that cleverly hidden in my statements were the words
"very few".
I did not say that 8.3 was dead.
BTW MS-DOS never ran on 8bit micros (if that's your implication) It did,
however, run on 16 bit micros with 8 bit buses
[snip]
> --
>
> Nate Eldredge
> [EMAIL PROTECTED]
--
John Gluck (Passport Kernel Design Group)
(613) 765-8392 ESN 395-8392
Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.
------------------------------
From: John Gluck <[EMAIL PROTECTED]>
Subject: Re: MBR
Date: Fri, 30 Jun 2000 10:23:16 -0400
Josef Moellers wrote:
> Andre Gauthier wrote:
> >
> > I was wondering if anybody knows where I can get some documentation t=
o
> > learn about MBR , and maybe even editing it.
> > Just curious...
>
> Quite a good description is in the LILO documentation.
>
> --
> Josef M=F6llers
> Fujitsu Siemens Computers
> SHV Server DS 1
There are also lots of web based docs. Try doing a search on MBR or "Mast=
er
Boot Record"
--
John Gluck (Passport Kernel Design Group)
(613) 765-8392 ESN 395-8392
Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.
------------------------------
From: Jem <[EMAIL PROTECTED]>
Subject: Re: Serial comms in C/C++/probably anything!
Date: Fri, 30 Jun 2000 15:33:08 +0100
Cheers, good thinking. I'll try that out.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jem wrote:
> >
> > Hi guys,
> >
> > I'm developing an application that takes bytes of a serial port and
> > throws them out of a socket interface onto a LAN. All is well and good
> > BUT how do I make sure that the bytes are "untampered" with, i.e. \r
> > hasn't been removed or changed into \n or \0 and ALL control codes will
> > pass through?
> >
> > There are loads of termios settings I realise but it would appear that
> > \r will be affected all the time by things like, what column is the
> > cursor in, etc... Am I reading the manuals wrong? Is there a nice
> > straightforward way of getting, byte by byte, each /dev/ttyS0 byte?
> >
> > Currently I'm using open() and read() to get the bytes...Maybe I need to
> > go to a lower level somehow? I mean, transferring of binary data over a
> > com port must be possible, it's just the books seem to approach it from
> > the point of view of talking to headless server devices and the like.
> >
> > The options I have come up with so far would be:
> >
> > c_iflag : IGNBRK
> > ~ISTRIP
> > ~INLCR
> > ~IGNCR
> > ~ICRNL
> >
> > c_oflag : OPOST
> > ~ONOCR
> > ~OCRNL
> > ~ONLRET
> >
> > c_cflag : CLOCAL
> > CS8 8 bit
> > ~CSTOPB
> > ~HUCPL
> >
> > Do I need ALL of these constants in termios or am I going about it all
> > wrong?
> >
> > Thanks for any help,
> >
> > Jeremy
>
> The last time I had to futz with this, which was only a month ago, the least
> painful solution was as follows:
>
> stty --file /dev/ttyS0 raw
> open the device and do a tcgetattr
------------------------------
From: Jerome Corre <[EMAIL PROTECTED]>
Subject: making a boot/root disk- >libraries too big!!
Date: Fri, 30 Jun 2000 14:30:17 GMT
hi,
I am trying to make a boot/root disk
I want to use sysVinit and bash, they use the following libraries:
init:
libc.so.6 => /lib/libc.so.6 (0x40018000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
bash:
libtermcap.so.2 => /lib/libtermcap.so.2 (0x40018000)
libc.so.6 => /lib/libc.so.6 (0x4001d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
some of those libraries are rather large and won't fit on my disk:
libtermcap.so.2 -> 15kb
/lib/libc.so.6 -> 4118kb
/lib/ld-linux.so.2 -> 344k
what can i do about it? is it possible to reduce the size of the
libraries and keeping only what i need in it? would it be better to
recompile init and bash in static mode? any other suggestion?
(i know there are some smaller shell (ash...) but i'd like to use bash
anyway, so that i don't have to rewrite the rc script to suit the
smaller shell)
I want to create a boot disk to run a old pc with no hard disk, 16MB of
ra, no screen, and a network car. this 'bizare' old pc is connected to
a newer one (with a screen) via a LAN. what i want to do is telnet the
noscreen PC from the newer PC, what do i need on the boot/root disk?
are getty, and bash required at all?
--
Jerome Corre
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Duke Lee" <[EMAIL PROTECTED]>
Subject: help: how to exhange data between user and kernel
Date: Fri, 30 Jun 2000 11:50:05 -0700
Before anything, thank you for any help you can give it on this. I have been
struggling with this for a long time.
I am designing a network device driver with the following structure.
______________
| Kernel Space |
|______________|
^ |
| V
______________
| User Space |
|______________|
^ |
| V
______________
| Kernel Space |
|______________|
The reason that I am doing this is because the user program has been
generated by a code generater that has its own scheduler.
Basically I would like to know a asynchronous way to exchange data between
the the kernel space and the user space.
What I have done so far:
I tried to use the /proc file system, following the code and the instruction
from Mr. Ori Pomerantz. I also added poll to one of its functions to
exchange data asynchronously. First I am not sure if the select function
that I wrote works at all. Now I am not even sure if this is the right way,
because I don't understand how to control when the kernel writes to the
/proc file.
What I have question on:
*****************************************
1) Is the poll function correct?
/* -duke copied from kmsg.c */
struct wait_queue * procfs_wait = NULL;
static unsigned int kmsg_poll(struct file *file, poll_table * wait)
{
poll_wait(file, &procfs_wait, wait);
return POLLIN | POLLRDNORM;
}
*******************************************
2) From look at the output of the functions, one can see that the user
function misses one of the writes. What is going on?
1 Last input:This is message from user 1
�w����5@�C@��������!
1 Last input:This is message from user 1
�w����5@�C@��������!
2 Last input:This is message from user 3
�w����5@�C@��������!
2 Last input:This is message from user 3
�w����5@�C@��������!
3 Last input:This is message from user 5
�w����5@�C@��������!
3 Last input:This is message from user 5
�w����5@�C@��������!
4 Last input:This is message from user 7
�w����5@�C@��������!
4 Last input:This is message from user 7
�w����5@�C@��������!
5 Last input:This is message from user 9
�w����5@�C@��������!
5 Last input:This is message from user 9
�w����5@�C@��������!
*****************************************
3) When does the kernel write into the proc file system?
*****************************************
The following are the module file and the user file for reference
*****************************************
* procfs.c
*****************************************
/* procfs.c - create a "file" in /proc, which allows
* both input and output. */
/* Copyright (C) 1998-1999 by Ori Pomerantz */
/* The necessary header files */
/* - duke from kmsg.c */
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/sched.h>
#include <linux/poll.h>
#include <asm/io.h>
/* Standard in kernel modules */
#include <linux/kernel.h> /* We're doing kernel work */
#include <linux/module.h> /* Specifically, a module */
/* Deal with CONFIG_MODVERSIONS */
#if CONFIG_MODVERSIONS==1
#define MODVERSIONS
#include <linux/modversions.h>
#endif
/* Necessary because we use proc fs */
#include <linux/proc_fs.h>
/* In 2.2.3 /usr/include/linux/version.h includes a
* macro for this, but 2.0.35 doesn't - so I add it
* here if necessary. */
#ifndef KERNEL_VERSION
#define KERNEL_VERSION(a,b,c) ((a)*65536+(b)*256+(c))
#endif
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
#include <asm/uaccess.h> /* for get_user and put_user */
#endif
/* -duke to get rid of the warning message during compilation */
extern int sprintf(char * buf, const char * fmt, ...);
/* The module's file functions ********************** */
/* Here we keep the last message received, to prove
* that we can process our input */
#define MESSAGE_LENGTH 80
static char Message[MESSAGE_LENGTH];
int count = 0;
/* -duke copied from kmsg.c */
struct wait_queue * procfs_wait = NULL;
static unsigned int kmsg_poll(struct file *file, poll_table * wait)
{
poll_wait(file, &procfs_wait, wait);
return POLLIN | POLLRDNORM;
}
/* Since we use the file operations struct, we can't
* use the special proc output provisions - we have to
* use a standard read function, which is this function */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
static ssize_t module_output(
struct file *file, /* The file read */
char *buf, /* The buffer to put data to (in the
* user segment) */
size_t len, /* The length of the buffer */
loff_t *offset) /* Offset in the file - ignore */
#else
static int module_output(
struct inode *inode, /* The inode read */
struct file *file, /* The file read */
char *buf, /* The buffer to put data to (in the
* user segment) */
int len) /* The length of the buffer */
#endif
{
static int finished = 0;
int i;
char message[MESSAGE_LENGTH+30];
/* We return 0 to indicate end of file, that we have
* no more information. Otherwise, processes will
* continue to read from us in an endless loop. */
if (finished) {
finished = 0;
return 0;
}
/* We use put_user to copy the string from the kernel's
* memory segment to the memory segment of the process
* that called us. get_user, BTW, is
* used for the reverse. */
sprintf(message, "%d Last input:%s", count, Message);
for(i=0; i<len && message[i]; i++)
put_user(message[i], buf+i);
count++;
/* Notice, we assume here that the size of the message
* is below len, or it will be received cut. In a real
* life situation, if the size of the message is less
* than len then we'd return len and on the second call
* start filling the buffer with the len+1'th byte of
* the message. */
finished = 1;
return i; /* Return the number of bytes "read" */
}
/* This function receives input from the user when the
* user writes to the /proc file. */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
static ssize_t module_input(
struct file *file, /* The file itself */
const char *buf, /* The buffer with input */
size_t length, /* The buffer's length */
loff_t *offset) /* offset to file - ignore */
#else
static int module_input(
struct inode *inode, /* The file's inode */
struct file *file, /* The file itself */
const char *buf, /* The buffer with the input */
int length) /* The buffer's length */
#endif
{
int i;
/* Put the input into Message, where module_output
* will later be able to use it */
for(i=0; i<MESSAGE_LENGTH-1 && i<length; i++)
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
get_user(Message[i], buf+i);
/* In version 2.2 the semantics of get_user changed,
* it not longer returns a character, but expects a
* variable to fill up as its first argument and a
* user segment pointer to fill it from as the its
* second.
*
* The reason for this change is that the version 2.2
* get_user can also read an short or an int. The way
* it knows the type of the variable it should read
* is by using sizeof, and for that it needs the
* variable itself.
*/
#else
Message[i] = get_user(buf+i);
#endif
Message[i] = '\0'; /* we want a standard, zero
* terminated string */
/* We need to return the number of input characters
* used */
return i;
}
/* The file is opened - we don't really care about
* that, but it does mean we need to increment the
* module's reference count. */
int module_open(struct inode *inode, struct file *file)
{
MOD_INC_USE_COUNT;
return 0;
}
/* The file is closed - again, interesting only because
* of the reference count. */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
int module_close(struct inode *inode, struct file *file)
#else
void module_close(struct inode *inode, struct file *file)
#endif
{
MOD_DEC_USE_COUNT;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
return 0; /* success */
#endif
}
/* Structures to register as the /proc file, with
* pointers to all the relevant functions. ********** */
/* File operations for our proc file. This is where we
* place pointers to all the functions called when
* somebody tries to do something to our file. NULL
* means we don't want to deal with something. */
static struct file_operations File_Ops_4_Our_Proc_File =
{
NULL, /* lseek */
module_output, /* "read" from the file */
module_input, /* "write" to the file */
NULL, /* readdir */
kmsg_poll, /* select */
NULL, /* ioctl */
NULL, /* mmap */
module_open, /* Somebody opened the file */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
NULL, /* flush, added here in version 2.2 */
#endif
module_close, /* Somebody closed the file */
/* etc. etc. etc. (they are all given in
* /usr/include/linux/fs.h). Since we don't put
* anything here, the system will keep the default
* data, which in Unix is zeros (NULLs when taken as
* pointers). */
};
/* Inode operations for our proc file. We need it so
* we'll have some place to specify the file operations
* structure we want to use, and the function we use for
* permissions. It's also possible to specify functions
* to be called for anything else which could be done to
* an inode (although we don't bother, we just put
* NULL). */
static struct inode_operations Inode_Ops_4_Our_Proc_File =
{
&File_Ops_4_Our_Proc_File,
NULL, /* create */
NULL, /* lookup */
NULL, /* link */
NULL, /* unlink */
NULL, /* symlink */
NULL, /* mkdir */
NULL, /* rmdir */
NULL, /* mknod */
NULL, /* rename */
NULL, /* readlink */
NULL, /* follow_link */
NULL, /* readpage */
NULL, /* writepage */
NULL, /* bmap */
NULL, /* truncate */
NULL /* module_permission */ /* check for permissions */
};
/* Directory entry */
static struct proc_dir_entry Our_Proc_File =
{
0, /* Inode number - ignore, it will be filled by
* proc_register[_dynamic] */
7, /* Length of the file name */
"rw_test", /* The file name */
S_IFREG | S_IRUGO | S_IWUSR,
/* File mode - this is a regular file which
* can be read by its owner, its group, and everybody
* else. Also, its owner can write to it.
*
* Actually, this field is just for reference, it's
* module_permission that does the actual check. It
* could use this field, but in our implementation it
* doesn't, for simplicity. */
1, /* Number of links (directories where the
* file is referenced) */
0, 0, /* The uid and gid for the file -
* we give it to root */
80, /* The size of the file reported by ls. */
&Inode_Ops_4_Our_Proc_File,
/* A pointer to the inode structure for
* the file, if we need it. In our case we
* do, because we need a write function. */
NULL
/* The read function for the file. Irrelevant,
* because we put it in the inode structure above */
};
/* Module initialization and cleanup ******************* */
/* Initialize the module - register the proc file */
int init_module()
{
/* Success if proc_register[_dynamic] is a success,
* failure otherwise */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
/* In version 2.2, proc_register assign a dynamic
* inode number automatically if it is zero in the
* structure , so there's no more need for
* proc_register_dynamic
*/
return proc_register(&proc_root, &Our_Proc_File);
#else
return proc_register_dynamic(&proc_root, &Our_Proc_File);
#endif
}
/* Cleanup - unregister our file from /proc */
void cleanup_module()
{
proc_unregister(&proc_root, Our_Proc_File.low_ino);
}
*****************************************
* user.c
*****************************************
#include <sys/poll.h>
#include <sys/stat.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>
#define BUFFERSIZE 80
main()
{
int n_read = 0;
int n_write = 0;
int counter = 1;
char buffer[BUFFERSIZE];
char readbuffer[BUFFERSIZE];
struct pollfd ufds[1];
ufds->events = POLLIN;
ufds->fd = open("/proc/rw_test", O_RDWR);
while (1)
{
/* write */
sprintf(buffer, "This is message from user %d\n", counter);
n_write = write(ufds->fd, buffer, BUFFERSIZE);
/* read */
if (poll(ufds,1,1000))
n_read = read(ufds->fd, readbuffer, BUFFERSIZE);
printf("%s\n", readbuffer);
counter++;
}
sleep(1);
}
close(ufds->fd);
}
------------------------------
** 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
******************************
