Linux-Development-Sys Digest #655, Volume #6     Tue, 27 Apr 99 09:14:22 EDT

Contents:
  Powwerdown on shutdown for 2.2.6 laptop ([EMAIL PROTECTED])
  Re: Symbolic link and chroot ("G. Sumner Hayes")
  Re: compiling against libc5 libraries under RedHat 5.2 ("sj")
  Programming the M68HC11 MCU with Linux Hosts (Rafael R. Sevilla)
  Re: M-systems binary only drivers & GPL (Bjorn Eriksson)
  iso image of redhat distribution ? (Christoph Klaja)
  exhausted memory questions ([EMAIL PROTECTED])
  Re: redhat 6.0? ("Bob Taylor")
  Re: Advice wanted on Device Driver design (Emile van bergen)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED]
Subject: Powwerdown on shutdown for 2.2.6 laptop
Date: Tue, 27 Apr 1999 02:31:05 GMT

I recently upgraded Sony pcg-f160 laptop running linux from 2.0.36 to 2.0.6.
the Powerdown on shutdown used to work but now I can not seem to make
function. Any clues?

Ross

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Symbolic link and chroot
Date: Tue, 27 Apr 1999 01:57:36 -0400

Andreas Schwab wrote:
> 
> David Corredor Lacha <[EMAIL PROTECTED]> writes:
> |>      Yes, my problem is how to do a symbolic link in a chroot
> |> environment to a extern file. I see some times ago a library
> |> to do it, but I don't remember where find it.
> 
> You can't.  Symbolic links are always interpreted in the context of 
> the current process.  Only hard links can refer to files outside the 
> chroot jail, if they were created before.

Technically, if there is a hard link to the file inside the chroot
jail then the file isn't outside of the chroot jail.  There is no
difference between a hard link and the original file -- they're both
just links in the fs namespace, and the file stays around until there
are no links left to it.  Once you've chroot'd, then in theory the
new root directory is the root directory and there's no way to get out.
The theory generally holds for non-root users -- if not, it's a kernel
bug.  For people with root (or chroot capability on a capabilities-
based system) I don't know what is the current state of affairs.  It
used to be that root could chroot("../../../../../../../../") to get
out of jail free.  If that's an issue for you, you probably ought to
investigate the current situation.

--Sumner

------------------------------

From: "sj" <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc.help,comp.os.linux.development.apps
Subject: Re: compiling against libc5 libraries under RedHat 5.2
Date: Mon, 26 Apr 1999 22:39:32 -0700

Use the file extension .cc and use the command g++ -o outfile.out infile.cc
-Stuart

Julian Laxton <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> All,
>     I have a C++ application I'm trying to compile under RedHat 5.2.
> The problem is that the code requires Motif, and my version of the Motif
> libraries is libc5.  I have successfully compiled "plain" c code against
> the Motif library, using a package called gcc5-1.0-1.i386.rpm.  This
> package provides a script that invokes the gcc compiler version supplied
> with RedHat 4.2.  Is there a similar package that will allow me to
> compile C++ code?  If not, what do I have to do to compile C++ code
> against the libc5 style libraries?
>
> TIA,
> Julian Laxton
> [EMAIL PROTECTED]
>
>
>



------------------------------

From: Rafael R. Sevilla <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded,sci.electronics
Subject: Programming the M68HC11 MCU with Linux Hosts
Date: Tue, 27 Apr 1999 08:52:36 GMT



I was wondering what is the proper way to program the M68HC11 family of
microcontrollers with a Linux (or any Unix variant with termios-compatible
serial programming facilities for that matter) host, in particular sending
programs via its special bootstrap mode.  Following the Linux
Serial-Programming-HOWTO, I was able to do this successfully, but oddly, the
same code that runs on my Linux notebook stoutly refuses to run anywhere else.
The serial port devices can't even be opened (and yes, the permissions are
properly set). And it doesn't run particularly well on my notebook either.  It
takes an unreasonably long time to start up and download a single 256-byte
bootstrap program, which should take just under three seconds at 1200 baud,
including the verification characters, but times in excess of 10 seconds are
common.  It eventually *works*, I must emphasize, and later uses of the serial
port don't seem to suffer from these effects (once my own programs are running
on the chip, that is).  It's very frustrating.

---
TOMORROW?! But I haven't even prepared for YESTERDAY YET!

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: [EMAIL PROTECTED] (Bjorn Eriksson)
Subject: Re: M-systems binary only drivers & GPL
Date: Tue, 27 Apr 1999 11:46:48 +0200

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
says...
> 
> I saw that several compagnies are using the M-Systems
> (http://www.m-sys.com) disk-on-chip products with Linux. It emulates a
> hard disk with flash memory.
> 
> 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.

 They also provides a "modified LILO" that they called plilo without 
source code. Assuming they didn't write this from scratch I find this an 
even bigger GPL abuse.


//Bj�rn Eriksson

------------------------------

From: Christoph Klaja <[EMAIL PROTECTED]>
Subject: iso image of redhat distribution ?
Date: Tue, 27 Apr 1999 12:03:34 +0200

hi...

does anyone know where there is an iso-image available of redhat 5.2+ ?

TIA

c ya
__
\__HRIS


------------------------------

From: [EMAIL PROTECTED]
Subject: exhausted memory questions
Date: Tue, 27 Apr 1999 09:56:02 GMT

I remember (when I had a CDR), that when I played back the freshly ripped
songs, to check for defects and errors, I would pop up "top" and slowly see
the "free" memory decrease until it was about 1M or less.  Then the player
would start to sound distorted (crackles and pauses, as if it were waiting
for free memory), all of a sudden I would get an error like "Unable to open:
Insufficient memory" or similar.  I would be unable to play any sounds and
the only way for me to get this memory would be to reboot, and if I opened
any other programs such as X, I would notice a slowdown in performance.

Well my questions are:

Can memory be freed manually? (still haven't a recently posted code) Why do
sounds use up memory when they are played directly through the device? Is
there some way to move "used" memory to the "free" area? Why do my schools
system administrators always delete my Linux partition on the computer I use
in the lab? (Windows uses 500M, and 1.5G are unused, per computer in about
25+, don't answer this one, it's just to vent-off some steam)

Thanks.

PS I have already been told not to worry, it's just that it bothers me to have
no
memory left.  Today I was compiling "KDE" with no swapspace, and I got the
exhausted memory error, my "free" memory was at about 233k.  I add a swapfile,
and it worked but the "free" memory never regained it's strength after that.

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] ("Bob Taylor")
Subject: Re: redhat 6.0?
Crossposted-To: comp.os.linux.advocacy
Date: Tue, 27 Apr 1999 07:00:07 GMT

In article <[EMAIL PROTECTED]>,
        Al <[EMAIL PROTECTED]> writes:
> 
> What are the show stopper bugs in Gnome?

The one I dislike the most is upon login the swallowed apps fail and
cannot be restarted. I use multiple desktops and areas (3x3 and 4 desktops).
Without the pager life is difficult. So far logging out then back in
resolves the error. However I must redo the swallowed apps. Gnome-terminal
segfaults (IIRC).

-- 
+----------------------------------------------------------------+
| Bob Taylor             Email: [EMAIL PROTECTED]             |
|----------------------------------------------------------------|
| Gnome certainly is (serious competition to the Mac or Windows) |
| ... I get a charge out of seeing the X Window System work the  |
| way we intended..." - Jim Gettys                               |
+----------------------------------------------------------------+

------------------------------

From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: Advice wanted on Device Driver design
Date: Tue, 27 Apr 1999 11:11:20 +0200


First, I don't know exactly about how this exposing you mention should
be a problem: if the key buffer is in kernel space, no process (without
root access that is, otherwise there's /proc/kcore) can read it from
there.

But something else: judging from the sequence below I take it you'd
buffer the whole message in kernel space... Wouldn't it be nicer to
implement something like 'sec_pipe(2)' (like a normal pipe, but
encrypting the data that flows trough it) or a pseudo-tty like scheme,
i.e. with a master and a slave side? You would then be able to encrypt
arbitrary-sized messages.

Furthermore, if you'd pass the key when creating the pipe, the key could
set up some derived state tables (what algorithm do you use?) while
overwriting the actual key itself (as soon as each byte is processed) So
there would be a very limited time in which the real key is visible,
even in kernel space.

Hope this is of any help...


On Mon, 26 Apr 1999, Lew Pitcher wrote:

>A first cut at the sequence that the driver would handle looks like...
>a) open the device (say /dev/crypto), which would lock the device
>   with a semiphore lock. Other processes would wait on open until
>   the owning process closes the device.
>
>b) the process would write() the unencrypted message to the device
>
>c) the process would ioctl() (or otherwise) set the encryption key
>
>d) the process would read() the encrypted message from the device
>
>e) the process would close the device (causing the device driver to
>   wipe all recorded information, including the encryption key)

-- 

M.vr.gr. / Best regards,

Emile van Bergen (e-mail address: [EMAIL PROTECTED])

This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.


------------------------------


** 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
******************************

Reply via email to