Linux-Development-Sys Digest #100, Volume #8 Thu, 24 Aug 00 17:13:12 EDT
Contents:
Re: crypt(3) (Fro-Man)
Re: all threads in a process share the same pid? (Tony Gale)
Measuring the idle time for ide disk (Ravi Wijayaratne)
Re: Programming /dev/ttyS* in Unix (Mario Klebsch)
Re: crypt(3) ([EMAIL PROTECTED])
Re: crypt(3) (Fro-Man)
Re: login and passwd problems with glibc (crypt) [problem solved] (Vincent Stemen)
Re: login and passwd problems with glibc (crypt) [problem solved] (Vincent Stemen)
Device Driver for Acer Southbridge 1535 (Stephen Rousset)
APM BIOS access on TP 600x ("Chris Zimmermann")
Programming of continuous exchange on TCP/IP ("Pliev")
Re: Linux driver module question ("Norm Dresner")
----------------------------------------------------------------------------
From: Fro-Man <[EMAIL PROTECTED]>
Subject: Re: crypt(3)
Date: Thu, 24 Aug 2000 12:05:11 -0400
On Thu, 24 Aug 2000 [EMAIL PROTECTED] wrote:
> It should be in the man page, I think he fact that it isn't is just a
> historical artifact. It's always been a static buffer, and everyone
> knows it sort of thing. ;)
Nod, that might be it...
> Having it return a malloc'd instance, however, is _not_ a better idea
> for two reasons. First, very few people are actually concerned with
> keeping the hash around after the next call to crypt(). On top of
> that, there are significant numbers of functions which return data in
> a static buffer besides crypt(), so it's more in keeping with the rest of
> the library.
Hmmm, I guess that is acceptable. I am using it in a threaded chat server
I am writing, and I want to avoid the possibility one person logs in wiht
another's password accidently. So, basically I am having to put a mutex
around the crypt() and a strcpy(). So, it just seems like a waste. I
suppose this might be a more rare instance how I am using it... Oh-well.
Aaron Day / Keep the milk in /
[EMAIL PROTECTED] / the cow, if you /
http://www.csis.gvsu.edu/~daya / don't want it to sour /
------------------------------
From: [EMAIL PROTECTED] (Tony Gale)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: 24 Aug 2000 16:13:49 GMT
In article <Gibp5.44405$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
>
> I think, and I could be wrong, that it will still be possible to
> violate the standard, unless some system calls are modified to be
> "thread aware" at the same time. It looks to me like it would fix most
> of the big issues though. And, more importantly, _all_ of the kernel
> ones.
>
Well, it should certainly fix the single PID and signal handling issues,
which would then make it POSIX compliant, AFAIK.
-tony
--
E-Mail: Tony Gale <[EMAIL PROTECTED]>
The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.
------------------------------
From: Ravi Wijayaratne <[EMAIL PROTECTED]>
Subject: Measuring the idle time for ide disk
Date: Thu, 24 Aug 2000 06:14:02 -0500
Reply-To: [EMAIL PROTECTED]
Hi,
I am interested in measuring the idle time of the ide disk when there
is a steady stream of requests queued to the device to get an idea of
the disk utilization. I have looked at the ide device driver code
drivers/block/ide.c and drivers/block/ide-disk.c.
I believe that ide_do_request is called any time a request is scheduled
to the drive. This is called by unplug_device(in
drivers/block/ll_rw_blk.c) and ide_intr() (in ide.c).
I need to call a function which triggers an idle timer as soon as the
device goes idle. I am a little bit confused about how ide_do_request
determines whether the drive is idle or not. Specifically the use
of the hwgroup->busy , drive->sleep and choose_drive(hwgroup) function.
does hwgroup->busy = 0 imply that this hwgroup is idle ?
What is the purpose of making the driver sleep ?
Code snippet from ide.c function do_ide_request. I have put a comment in
that in the place I think it is safe to assume that the drive is idle.
Is it accurate ?
I am interested in a case where there is only one drive in a hardware
interface and only one hardware interface is active. But comments about
other cases are also welcome.
Some help is much appreciated.
Ravi
Linux version 2.2.14
====================ox========
static void ide_do_request (ide_hwgroup_t *hwgroup, int masked_irq)
{
struct blk_dev_struct * bdev;
ide_drive_t *drive;
ide_hwif_t *hwif;
ide_startstop_t startstop;
ide_get_lock(&ide_lock, ide_intr, hwgroup); /* for atari only:
POSSIBLY BROKEN HERE(?) */
while (!hwgroup->busy) {
hwgroup->busy = 1;
drive = choose_drive(hwgroup);
if (drive == NULL) {
unsigned long sleep = 0;
hwgroup->rq = NULL;
drive = hwgroup->drive;
do {
bdev = &blk_dev[HWIF(drive)->major];
if (bdev->current_request != &bdev->plug) /* FIXME: this
will do for now */
bdev->current_request = NULL; /* (broken since
patch-2.1.15) */
if (drive->sleep && (!sleep || 0 < (signed long)(sleep -
drive->sleep)))
sleep = drive->sleep;
} while ((drive = drive->next) != hwgroup->drive);
if (sleep) {
/*
* Take a short snooze, and then wake up this hwgroup again.
* This gives other hwgroups on the same a chance to
* play fairly with us, just in case there are big
differences
* in relative throughputs.. don't want to hog the cpu too
much.
*/
if (0 < (signed long)(jiffies + WAIT_MIN_SLEEP - sleep))
sleep = jiffies + WAIT_MIN_SLEEP;
hwgroup->sleeping = 1; /* so that ide_timer_expiry knows
what to do */
#if 1 /* paranoia */
if (hwgroup->timer.next || hwgroup->timer.prev)
printk("ide_set_handler: timer was already active\n");
#endif
mod_timer(&hwgroup->timer, sleep);
/* we purposely leave hwgroup->busy==1 while sleeping */
} else {
/* Ugly, but how can we sleep for the lock otherwise?
perhaps
from tq_scheduler? */
ide_release_lock(&ide_lock); /* for atari only */
/----------------------------------------------------------------------------------------------/
/------------- IS THIS THE PLACE DRIVE IS IDLE ??????? /
hwgroup->busy = 0;
}
return; /* no more work for this hwgroup (for now) */
}
hwif = HWIF(drive);
if (hwgroup->hwif->sharing_irq && hwif != hwgroup->hwif) /* set
nIEN for previous hwif */
OUT_BYTE(hwgroup->drive->ctl|2,
hwgroup->hwif->io_ports[IDE_CONTROL_OFFSET]);
hwgroup->hwif = hwif;
hwgroup->drive = drive;
drive->sleep = 0;
drive->service_start = jiffies;
bdev = &blk_dev[hwif->major];
if (bdev->current_request == &bdev->plug) /* FIXME: paranoia */
printk("%s: Huh? nuking plugged queue\n", drive->name);
bdev->current_request = hwgroup->rq = drive->queue;
/*
* Some systems have trouble with IDE IRQs arriving while
* the driver is still setting things up. So, here we disable
* the IRQ used by this interface while the request is being
started.
* This may look bad at first, but pretty much the same thing
* happens anyway when any interrupt comes in, IDE or otherwise
* -- the kernel masks the IRQ while it is being handled.
*/
if (hwif->irq != masked_irq)
disable_irq_nosync(hwif->irq);
spin_unlock(&io_request_lock);
ide__sti(); /* allow other IRQs while we start this request */
startstop = start_request(drive);
spin_lock_irq(&io_request_lock);
if (hwif->irq != masked_irq)
enable_irq(hwif->irq);
if (startstop == ide_stopped)
hwgroup->busy = 0;
}
}
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: Programming /dev/ttyS* in Unix
Date: Wed, 23 Aug 2000 22:47:14 +0200
"Pliev" <[EMAIL PROTECTED]> writes:
>Do you can to say to me, how in Unix (Linux) can to program COM ports
>(/dev/ttyS*). Which functions I must to use? I programmed in Win32
>earlier, and used function CreateFile, WriteFile etc. Which analogs
>this functions using in Unix.
What about open(), read(), write(), close() & ioctl()?
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: crypt(3)
Date: Thu, 24 Aug 2000 17:34:52 GMT
Fro-Man <[EMAIL PROTECTED]> wrote:
> Hmmm, I guess that is acceptable. I am using it in a threaded chat server
> I am writing, and I want to avoid the possibility one person logs in wiht
> another's password accidently. So, basically I am having to put a mutex
> around the crypt() and a strcpy(). So, it just seems like a waste. I
> suppose this might be a more rare instance how I am using it... Oh-well.
No, crypt(3), and half of the "standard" library predate threads by a
substantial amount of time. That's why there are a plethora of _r
functions now.
The solution, of course, isn't to malloc memory in crypt(), but to
allow the user to pass a pointer to their own buffer as an additional
argument. Now all we need is a time machine. ;)
glibc also provides crypt_r in -lcrypt, but it's prototyped in
<crypt.h>.
char *crypt_r(const char *KEY, const chat *SALT, struct crypt_data *DATA)
The documentation for it is in the libc info pages, in the obvious
place.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Fro-Man <[EMAIL PROTECTED]>
Subject: Re: crypt(3)
Date: Thu, 24 Aug 2000 13:45:19 -0400
On Thu, 24 Aug 2000 [EMAIL PROTECTED] wrote:
> No, crypt(3), and half of the "standard" library predate threads by a
> substantial amount of time. That's why there are a plethora of _r
> functions now.
Hmmm, threads are relatively new to me. Hence, why I am trying to fool
around with them right now. I've been trying to read along with the
arguements in the NG here, though. Now, is there a place to get a listing
of those _r functions? Or is there a standard library of them?
> The solution, of course, isn't to malloc memory in crypt(), but to
> allow the user to pass a pointer to their own buffer as an additional
> argument. Now all we need is a time machine. ;)
That makes much more sense than malloc()'ing it. Good call.
> glibc also provides crypt_r in -lcrypt, but it's prototyped in
> <crypt.h>.
>
> char *crypt_r(const char *KEY, const chat *SALT, struct crypt_data *DATA)
>
> The documentation for it is in the libc info pages, in the obvious
> place.
Nod. Thanks a lot. This helps.
# Aaron Day # [EMAIL PROTECTED] # http://www.csis.gvsu.edu/~daya
'init' is the mother of all proccesses...
------------------------------
Crossposted-To: gnu.glibc.bug
Subject: Re: login and passwd problems with glibc (crypt) [problem solved]
From: Vincent Stemen <[EMAIL PROTECTED]>
Date: Thu, 24 Aug 2000 18:42:32 GMT
Vincent <[EMAIL PROTECTED]> writes:
> I cannot get login and passwd to work with glibc.
>
> I am running:
> AMD K6 processor
> linux-kernel-2.4.0-test4
> glibc-2.1.3
> configured with
> configure --host=i386-pc-linux-gnu --enable-add-ons \
> --prefix=/usr \
> --disable-sanity-checks
> egcs-1.1.2
> shadow-19990827
> util-linux-2.10k.package
>
> The passwd and login programs from the shadow package give the following
> error
>
> crypt: Operation not supported
>
> If I disable shadow and run passwd from the util-linux package, it acts like
> it successfully sets the password but the password field in /etc/passwd is
> still empty (I am starting with no password set).
>
> I have tried this with glibc compiled both with and withiout the crypt addon
> package.
>
> I have not found anything in the docs, FAQ's, or mailing lists that help.
> Does anybody have any idea what would cause this? Perhaps some
> configuration I am overlooking when compiling one of the packages?
>
> If you need any more information, I will gladly provide it.
> Please help if anybody out there can.
>
> Thanks in advance.
For those who are interested, I finally got it working.
As it turns out, apparently libc6 only supports md5 encryption without
the crypt addon. The shadow package needed
MD5_CRYPT_ENAB yes
to be set in /etc/login.defs to enable md5. This caused the salt
parameter to crypt() to contain "$1$" at the beginning of the string.
Without this in the salt string, crypt() could not generate the
password and hence the error
crypt: Operation not supported
got printed.
I still do not know why it I got the same error with the crypt addon
compiled into libc6 unless shadow does not support the new DES
encryption or there is some other configuration parameter I have not
discovered yet to enable it.
The passwd and login utils from the util-linux-2.10k also do not work
with libc6 and I have not found any reference to how to enable md5 in
that package. passwd acted like it changed the password with no
errors but no password got encrypted in /etc/passwd. Apparently glibc
does not support the old encryption that was used in libc5, which
means that shadow is the only package that works. That is ok since
shadow works with shadow passwords on or off.
I do like the fact that, with MD5, passwords can be longer (up to 127
characters). I just wish that these packages were documented better
as to which combinations work and which don't.
- Vincent
------------------------------
Subject: Re: login and passwd problems with glibc (crypt) [problem solved]
From: Vincent Stemen <[EMAIL PROTECTED]>
Date: Thu, 24 Aug 2000 18:50:42 GMT
Vincent <[EMAIL PROTECTED]> writes:
> I cannot get login and passwd to work with glibc.
>
> I am running:
> AMD K6 processor
> linux-kernel-2.4.0-test4
> glibc-2.1.3
> configured with
> configure --host=i386-pc-linux-gnu --enable-add-ons \
> --prefix=/usr \
> --disable-sanity-checks
> egcs-1.1.2
> shadow-19990827
> util-linux-2.10k.package
>
> The passwd and login programs from the shadow package give the following
> error
>
> crypt: Operation not supported
>
> If I disable shadow and run passwd from the util-linux package, it acts like
> it successfully sets the password but the password field in /etc/passwd is
> still empty (I am starting with no password set).
>
> I have tried this with glibc compiled both with and withiout the crypt addon
> package.
>
> I have not found anything in the docs, FAQ's, or mailing lists that help.
> Does anybody have any idea what would cause this? Perhaps some
> configuration I am overlooking when compiling one of the packages?
>
> If you need any more information, I will gladly provide it.
> Please help if anybody out there can.
>
> Thanks in advance.
For those who are interested, I finally got it working.
As it turns out, apparently libc6 only supports md5 encryption without
the crypt addon. The shadow package needed
MD5_CRYPT_ENAB yes
to be set in /etc/login.defs to enable md5. This caused the salt
parameter to crypt() to contain "$1$" at the beginning of the string.
Without this in the salt string, crypt() could not generate the
password and hence the error
crypt: Operation not supported
got printed.
I still do not know why it I got the same error with the crypt addon
compiled into libc6 unless shadow does not support the new DES
encryption or there is some other configuration parameter I have not
discovered yet to enable it.
The passwd and login utils from the util-linux-2.10k also do not work
with libc6 and I have not found any reference to how to enable md5 in
that package. passwd acted like it changed the password with no
errors but no password got encrypted in /etc/passwd. Apparently glibc
does not support the old encryption that was used in libc5, which
means that shadow is the only package that works. That is ok since
shadow works with shadow passwords on or off.
I do like the fact that, with MD5, passwords can be longer (up to 127
characters). I just wish that these packages were documented better
as to which combinations work and which don't.
- Vincent
------------------------------
From: Stephen Rousset <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.embedded,linux.dev.kernel
Subject: Device Driver for Acer Southbridge 1535
Date: Thu, 24 Aug 2000 14:09:29 -0500
Does anyone know where I may be able to find the source code for
a device driver for the Acer 1535 Southbridge. The only drivers found
so far were for Windows and were only binaries.
Thanks,
--
==============================================
= It's not Rocket Science, It's RocketLogix. =
==============================================
Stephen P. Rousset
Founding Member, Technical Staff
Manager Firmware Development
RocketLogix, Inc.
Wk: (972)930-1130
Fx: (972)930-1199
[EMAIL PROTECTED]
www.rocketlogix.com
------------------------------
From: "Chris Zimmermann" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.misc,comp.os.ms-windows.nt,comp.os.ms-windows.nt.misc,comp.os.ms-windows.nt.programmer.misc,comp.os.ms-windows.nt.kernel-mode,alt.linux,comp.sys.ibm.pc.hardware.systems,comp.sys.laptops
Subject: APM BIOS access on TP 600x
Date: Thu, 24 Aug 2000 21:03:30 +0100
I'm looking for a way to access the APM BIOS of a Thinkpad 600x from
NT 4.0 WS. I know that NT doesn't support any power saving modes; on
the other side, the 600x seems to support this as apm.c in the Linux
2.x kernels suggests.
SMAPI as defined by IBM for their Thinkpads and used by Linux tools
such as tpctl doesn't seem to be the answer as it only seems to
support _control_ over the various settings the hardware / BIOS
supports and no functionality to, for example, obtain the remaining
recharging time for the battery (which the fuel gauge from the IBM
tools running on NT _can_ obtain!). As an aside: function 22h (get
power settings) does not seem be supported on my 600x as the SMAPI
invocation returns 53h: function not supported.
I had a quick look around in segment 40h for a jump point into the APM
BIOS under NT (that's what I'm getting from apm.c and apm_bios.h in
the Linux kernel but maybe I'm interpreting this wrong). But no luck
here. Any suggestions how to get the access (real mode or virtual x86)
and jump point for that BIOS extension under NT? Any hints gladly
appreciated!
Answers please in this newsgroup or via email; I'll post a summary
if there are enough replies.
Chris
------------------------------
From: "Pliev" <[EMAIL PROTECTED]>
Subject: Programming of continuous exchange on TCP/IP
Date: Fri, 25 Aug 2000 00:45:46 +0400
Programming of continuous exchange on TCP/IP
Do somebody can to send to me simple examples of programm on C,
client and server for exchange on TCP/IP, which (exchange) is continuous.
I want to realize the next algorithm:
Server - socket Client
- bind - socket
- listen - connect
----------------------------------------------------------------------
Then waiting "connect" from client
After connect:
continuous loop: server - "send"
client - "read"
============================================================================
-
I attempted to use functions "accept-connect", but I can't to call the
function
"connect" on loop, I may to call this function may one time only.
But "accept" make "send" in reply "connect". But "connect" I can't to call
on
loop. And I can't to make continuous exchange client-server.
I think, there is need to use other algorithm, but I don't know how.
Give me, please, one idea only, and little example.
Thanks! Dima.
------------------------------
Reply-To: "Norm Dresner" <[EMAIL PROTECTED]>
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: Linux driver module question
Date: Thu, 24 Aug 2000 20:57:44 GMT
Unless I'm reading your question wrong, you seem to be asking how to prevent
the kernel from swapping out the physical memory on your PCI board. The
only way the kernel can do that is if you don't screw the board down tightly
enough.
Norm
Ed Hudson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I am writing a kernel module driver for a custom PCI based DSP board.
> The board needs access to physical memory locations. I am using
> virt_to_phys() to translate the addresses, but I believe I need to
> implement a locking mechanism so that the locations I refer to are not
> swapped. Does any have any suggestions on how I may go about doing
> this? Any links to reference materials or example drivers would be
> much appreciated.
>
>
> Thanks,
> Ed Hudson
>
------------------------------
** 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
******************************
