Linux-Development-Sys Digest #874, Volume #7     Thu, 18 May 00 14:13:16 EDT

Contents:
  Re: Need ideas for university funded project for linux (Doug Alcorn)
  Re: SINGAL bad. =?iso-8859-1?Q?=BF?= linux bug ? ("Arthur H. Gold")
  Re: Port availability under linux (Kaz Kylheku)
  Re: Need ideas for university funded project for linux (George Russell)
  Re: Need ideas for university funded project for linux (David Steinberg)
  Re: Need ideas for university funded project for linux (Someone)
  Re: porting NT device drivers to linux (Paul D. Smith)
  Re: Need ideas for university funded project for linux (JEDIDIAH)
  Re: does linux support RAMDISK??? (Lew Pitcher)
  Re: serial port RTS control ? (Mario Klebsch)
  Re: does linux support RAMDISK??? (Mario Klebsch)

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

Crossposted-To: 
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
From: Doug Alcorn <[EMAIL PROTECTED]>
Date: Thu, 18 May 2000 16:26:02 GMT


Lathi gets out a clue stick.

[EMAIL PROTECTED] (JEDIDIAH) writes:

> On Thu, 18 May 2000 04:49:10 GMT, Mongoose <[EMAIL PROTECTED]> wrote:
> >On Thu, 18 May 2000 01:00:45 GMT, [EMAIL PROTECTED] wrote:
> >
> >>> So what is the problem with doing this in the KDE desktop? 
> >>
> >>KDE isn't free.
> >
> >  uh what? I don't remember paying for KDE...
> 
>       It's base library is "owned" by a corporation.
> 
>       A good suggestion might be to replace libqt entirely with a
>       completely liberated clone. However, it's dubious whether or
>       not the KDE developers would actually take advantage of such
>       a thing.

First, the Qt library _is_ now free.  Trolltech decided to license it
using a "free" license.  Second, there already was (a now dead?)
project to reimplement Qt with a free license.  Third, if Qt weren't
free and there was a free compatible library, it doesn't matter if the
KDE developers used it or not.  The end user could without any
problems.  If the two libraries were compatible, then Qt based apps
would not even know that they weren't using Qt.
-- 
 (__)  Doug Alcorn (mailto:[EMAIL PROTECTED] - http://www.lathi.net)
 oo /  Win a 66MB capacity tape drive. Help me win too!
 |_/   http://www.ecrix.com/extreme/getReferrals.cfm?ref=7612

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

Date: Thu, 18 May 2000 11:37:48 -0500
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: SINGAL bad. =?iso-8859-1?Q?=BF?= linux bug ?

AFAIK, siginfo (at least currently) only works on real time signals
(i.e. sig > 32).
Sorry.

You _can_ write your handler like this:
#include <asm/sigcontext.h>
void handler( int sig, struct sigcontext scp ) {
=2E..
}

The offending address will be in scp.cr2

BTW - install this handler in the sa_handler field.

HTH,
--ag



David wrote:
> =

> HI,
> =

> I am trying to use si_sigaction to obtain memory direction error, but i=
t
> doesnt work.
> =

> I have proved it into Solaris System and it works OK.
> =

> I have attached the probe file:
> sigaltstack.c
> =

> I install a signal handler and then I produce bad mem access. The man
> says that is_addr should
> give me address direction error, but really says that I have access to
> 0x0 direction memory.
> =

> Please can anyone probe the code and send me the output.
> THANKS
> =

>   ---------------------------------------------------------------------=
---
> #include <stdio.h>
> #include <signal.h>
> =

> void trat_segv ( int s , siginfo_t *si , void *extra ) // __attribute__=
 (( section( ".shared") ))
> {
>   printf( "----SEGV -------------------\n" ) ;
>   printf( "SIGNAL_NUMBER: %d\n" , si -> si_signo ) ;
>   printf( "Errno value: %d\n" , si -> si_errno ) ;
>   printf( "Signal Code: %d\n" , si -> si_code ) ;
>   printf( "PID_T: %d\n" , si -> si_pid  ) ;
>   printf( "UID_T: %d\n" , si -> si_uid ) ;
>   printf( "SI_STATUS: %d\n" , si -> si_status ) ; /* Exit value or sign=
al */
>   printf( "SIGNAL VALUE: %d\n" , si -> si_value ) ;  /* Signal value */=

>   printf( "SIGNAL INT: %d\n" , si -> si_int ) ;    /* POSIX.1b signal *=
/
>   printf( "SI_PTR: %d\n" , si -> si_ptr ) ;    /* POSIX.1b signal */
>   printf( "SI_ADDR: %d\n" , si -> si_addr ) ;   /* Maemory location whi=
ch caused fault */
>   printf( "SI_BAND: %d\n" , si -> si_band ) ;   /* Band event */
>   printf( "SI_FD: %d\n" , si -> si_fd );     /* File descriptor */
> =

>   exit(0);
> }
> =

> int main ( )
> {
>   stack_t segv_stack ;
>   struct sigaction accion;
> =

>   segv_stack.ss_sp    =3D (void *)malloc( SIGSTKSZ )  ;
>   segv_stack.ss_size  =3D SIGSTKSZ   ;
>   segv_stack.ss_flags =3D 0 ;
> =

>   printf("Direcci=F3n baja de pila: %p, Direcci=F3n alta de pila: %p\n"=
,
>         segv_stack.ss_sp, segv_stack.ss_sp+SIGSTKSZ);
>   if ( sigaltstack ( &segv_stack , 0 ) < 0 )
>     {
>       perror( "SIGALTKSTACK: " ) ;
>       printf( "ARGUMENTOS:\nSP: %p\nSIZE: %d\nFLAGS: %d\n" ,
>               segv_stack.ss_sp , segv_stack.ss_size , segv_stack.ss_fla=
gs ) ;
> =

>       return ;
>     }
> =

> =

>   accion.sa_sigaction =3D trat_segv ;
>   sigemptyset(&accion.sa_mask);
>   accion.sa_flags =3D SA_RESTART | SA_NOCLDSTOP | SA_ONSTACK | SA_SIGIN=
FO ;
>   sigaction(SIGSEGV, &accion, NULL);
> =

>   {
>     int *a =3D (int *)0x1 ;
>     *a =3D 10 ;
>   }
>   return 0 ;
> }

-- =

Artie Gold, Austin, TX  (finger the cs.utexas.edu account for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
"I've had a perfectly wonderful evening. But this wasn't it." - G. Marx

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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: linux.redhat.devel
Subject: Re: Port availability under linux
Reply-To: [EMAIL PROTECTED]
Date: Thu, 18 May 2000 17:02:04 GMT

On 18 May 2000 11:39:09 GMT, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Nicolas Bellardie  <[EMAIL PROTECTED]> wrote:
>>I'm experiencing a problem with ports under linux.
>>I'm developping a server process, and I want to close the socket that
>>makes a listen
>>on port X and reopen this socket later on the same port X.
>>Unfortunately, the port seems to be unavailable the second time.
>>If I stop the server process and run it again, the port has become
>>available again.
>
>Yes. Standard and required behaviour. Use setsockopt() and SO_LINGER
>if you want to change it - see man socket(7)

SO_LINGER only affects the behavior of close(), making it possible to wait for
a specified number of seconds for data to be drained the remote host.  If
close() is done on a socket for which lingering has not been turned on, or if
the socket is closed implicitly by exit(), the draining happens ``behind the
scenes''.

I think that Nicolas is running into TIME_WAIT problem, not CLOSE_WAIT
lingering.

He should specify the SO_REUSEADDR socket option each time he creates the
listening socket, sometime before calling bind() on it.

-- 
#exclude <windows.h>

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

From: [EMAIL PROTECTED] (George Russell)
Crossposted-To: 
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Reply-To: [EMAIL PROTECTED]
Date: Thu, 18 May 2000 17:08:33 GMT

On 18 May 2000 11:36:53 GMT, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>What most people don't like about KDE is that if you port your
>commercial program to Linux, you'll have to pay for a Qt license.

Proprietary program.... be accurate. Most KDE critics are hypocrites in this
way - critiscise closed apps, and cristicise a toolkit that makes them pay.

>Now that in itself is not so bad, but it's not fair. KDE is built
>on the kernel, X, gcc, you name it - all free. Yet you have to pay
>for this tiny Qt component. I'd rather pay Linus a few bucks for the
          ^^^^^^^^^^^^^^ 

How many man years? How many thousand lines of code? More importantly, how
many supplied features and capabilities? How much time and money saved by its
use? How often do you get cross windowing system portability built in?
Excellent support? Comprehensive docs? 

There are 100209 lines of code in .cpp and .h in Qt 2.1's src/kernel directory -
this misses out 3rd party stuff, the moc program, tools, dialogs, utils and
widgets, extensions (OpenGL support, Image formats, Xt widgets, NSPlugin), the
tutorial, includes, and examples... 

Quite a lot, I feel.

As a user, I've benefited from Qt's existance ever since the release of EzPPP 
using Qt. Since then, through the rise of KDE, and its Office suite and tools,
I habe continued to benefit and expect to benefit more.

I am grateful for Troll Techs liberal licensing terms.

George Russell

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

From: [EMAIL PROTECTED] (David Steinberg)
Crossposted-To: 
comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 18 May 2000 17:27:44 GMT

Peter T. Breuer ([EMAIL PROTECTED]) wrote:
: I use slackware and debian, and have no problems with either. I'd never
: touch redhat with a bargepole, since it's as nonstandard as hell. But

It seems to me like EVERY distribution is "non-standard"; they all seem to
put the same things in different places.  /usr or /usr/local?  /usr or
/opt?  /etc or /sbin?  Is there even a standard?  I'm really surprised
that this hasn't been fixed yet.  I can't imagine what benefit one gets
from putting stuff in a different plcae in the tree, other than the nice
feeling that his choice is more "logical."  However, the benefits for
having a common directory structure would be large.  In particular, people
wouldn't need to make 3 different rpm packages, for 3 different
distributions, and people would be much better able to share between rpm
and deb.  I must say that trying to fix this whole business with symlinks
from /opt to /usr is my biggest pet peeve.

What is the best way to fix this?  Should I just be helping repackage for
different distributions?  It seems futile since there are so many
packages appearing every day, and new distributions even pop up from time
to time.  Why can't RedHat, Debian, SuSE, Caldera, Slackware, and all just
get together and standardize this?  Has there ever been an effort to try?

(Sorry for drifting so far off-topic on such a massively cross-posted
thread)

--
David Steinberg                             -o)
Computer Engineering Undergrad, UBC         / \
[EMAIL PROTECTED]                _\_v


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

From: Someone <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Thu, 18 May 2000 13:36:25 -0400

What I would like is a kde multitrack recording application.  I would like
at least 8 tracks, loops, effects, mixing, bouncing, dehiss using a
sample, multiple sound cards, and the ability to output directly to cd
with named tracks.

Mongoose wrote:

> Hello,
>         I am attempting to start a college project and have two of my
> ideas already being worked on. So I wanted to know what other people
> had for suggestions for linux projects? I was thinking of something
> along the lines of a project that would help promote the use of linux.
> What is something that most people could use? Something that could
> make a good 1 year R&D project?


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

From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: porting NT device drivers to linux
Date: 18 May 2000 13:41:45 -0400
Reply-To: [EMAIL PROTECTED]

%% [EMAIL PROTECTED] (Mario Klebsch) writes:

  mk> But in this case, I probably would not use a ahared libary at
  mk> all. I would use a static library instead. The benefits of shared
  mk> libraries are only gained, if you have lots of programs all linked
  mk> against the same library (this can save a lot of space on disk)
  mk> and a large subset of these programs is executing simultaniously
  mk> (this will save RAM usage).

There's one other reason to use shared libs: you can swap out the shared
library with a newer version (if the interface is sufficiently similar)
without recompiling or re-installing any apps that use it.

With open source and package managers like DEB and RPM the utility of
this is much reduced, but it should be listed.

-- 
===============================================================================
 Paul D. Smith <[EMAIL PROTECTED]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
   These are my opinions---Nortel Networks takes no responsibility for them.

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

From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To: 
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Thu, 18 May 2000 17:44:32 GMT

On Thu, 18 May 2000 16:26:02 GMT, Doug Alcorn <[EMAIL PROTECTED]> wrote:
>
>Lathi gets out a clue stick.
>
>[EMAIL PROTECTED] (JEDIDIAH) writes:
>
>> On Thu, 18 May 2000 04:49:10 GMT, Mongoose <[EMAIL PROTECTED]> wrote:
>> >On Thu, 18 May 2000 01:00:45 GMT, [EMAIL PROTECTED] wrote:
>> >
>> >>> So what is the problem with doing this in the KDE desktop? 
>> >>
>> >>KDE isn't free.
>> >
>> >  uh what? I don't remember paying for KDE...
>> 
>>      It's base library is "owned" by a corporation.
>> 
>>      A good suggestion might be to replace libqt entirely with a
>>      completely liberated clone. However, it's dubious whether or
>>      not the KDE developers would actually take advantage of such
>>      a thing.
>
>First, the Qt library _is_ now free.  Trolltech decided to license it

        It's 'kinda' free. It's still owned by Trolltech.

        Should Trolltech get scooped up by alien, it will be free.

[deletia]

        The ultimate proof is in the ports: So where are those Be and Mac
        versions?

        Contributors are, afterall, the whole point of a Free licence.

-- 

    In what language does 'open' mean 'execute the evil contents of'    |||
    a document?      --Les Mikesell                                    / | \
    
                                      Need sane PPP docs? Try penguin.lvcm.com.

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

From: [EMAIL PROTECTED] (Lew Pitcher)
Subject: Re: does linux support RAMDISK???
Reply-To: [EMAIL PROTECTED]
Date: Thu, 18 May 2000 17:49:51 GMT

On Thu, 18 May 2000 16:03:32 +0200, Josef Moellers
<[EMAIL PROTECTED]> wrote:

>Lew Pitcher wrote:
>> =
>
>> On Thu, 18 May 2000 14:39:09 +0200, Josef Moellers
>> <[EMAIL PROTECTED]> wrote:
>
>> >Why, you can always swap out to disk what you can't keep in RAM!
>> =
>
>> I don't know about the Linux 2.2 implementation, but Linux 2.0 used
>> the kernel I/O buffer cache to build the ramdisk. AFAIK, the kernel
>> I/O buffer cache isn't swappable, and for ramdisks the pages are
>> explicitly marked as "BH_Protected". Additionally, for initrd
>> ramdisks, the space is directly allocated out of kernel
>> (non-swappable) memory via kmalloc() calls.
>
>You chopped off the "SCNR", whcih I thought would indicate that I wan't
>quite serious.

Oops... I missed that (and besides, that's an acronym that I don't
know) ;-)

>Obviously, swapping out a RAMDISK to a physical disk doesn't really make
>sense.

Not entirely true. In some systems, access to paging space (i.e. swap
partitions) can be faster and more efficient than access to filespace.
Some operating systems implement the equivalent of RAMDISKs in paged
memory, so that they gain the benefit of an in-core filesystem without
the memory requirements. It works faster than a full-dasd filesystem
(because you don't have to sync at a file component level), but (of
course) is slower than real memory. I thought that perhaps you were
refering to such a filesystem.

>You either have a ramdisk because you want the speed, then you really
>don't want mechanical disk access or you have the ramdisk because you
>don't have a functional disk at that time, in which case you can't swap
>either.

That's the primary reason you'd want a Linux ramdisk. Perhaps the OP
had other ideas, though <g>

>I'll add more B-{) in the future. Sorry,

No need. I'll just read a little more throughly in the future. <g>


>
>-- =
>
>Josef M=F6llers
>Fujitsu Siemens Computers
>SHV Server DS 1


Lew Pitcher
System Consultant
Toronto Dominion Financial Group

([EMAIL PROTECTED])


(Opinions expressed are my own, not my employer's.)

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

From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: serial port RTS control ?
Date: Thu, 18 May 2000 19:56:31 +0200

"Fred" <[EMAIL PROTECTED]> writes:

>I need to force high RTS line of a serial port before sending data and
>return it into normal state after transmission.

I have done this in Linux, but it required some changes to the serial
device drivers. My changed were that ugly (at one point I had to poll
a bit inthe UARTs status register), that I do not wantto publisch
them.

>Under SCO ODT, I set c_cflag to (ORTSFL|RTSFLOW)&~CTSFLOW) with ioctl and
>everything works fine
>but this masks are not defined in <bits/termios.h> under my RedHat 6.2 :-(

>Is it possible to just redefine this mask with SCO values ?
>Is there an other way to make RTS working like I need ?

Even my sollution required, that the user program sets the state of
RTS. My addition to the kernel was to add some syncronisation to the
serial data stream, which shifts out of TxD while sending. This is
needed at the point, where you deassert RTS.

I added a modification to the ioctl routine, which sets/resets RTS to
wait until the output Queue, the internal FIFO of the UART and the
shift register are empty. When waiting for the shift register to be
empty, I had to poll a bit of the UART.

73, Mario
-- 
Mario Klebsch                                           [EMAIL PROTECTED]

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

From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: does linux support RAMDISK???
Date: Thu, 18 May 2000 19:48:43 +0200

Josef Moellers <[EMAIL PROTECTED]> writes:
>Lew Pitcher wrote:
>Obviously, swapping out a RAMDISK to a physical disk doesn't really make
>sense.

IMHO it dies make sense. Linux is not an OS like the other on personal
computers. In Linux, like in other UNIX systems, you do have a system
administrator, who configures the system for you. The system
administrator has to do lots of decisions for you and normally, you do
not have the access rights, to change these decisions, when you
realize, they do not fit your needs.

>You either have a ramdisk because you want the speed, then you really
>don't want mechanical disk access or you have the ramdisk because you
>don't have a functional disk at that time, in which case you can't swap
>either.

So, having a RAM disk in virtual memory, gives you the choice to make
the ramdisk big enough, but at the same time not reducing the amount
of RAM available. If an appication needs the big ramdisk, fine, it can
use it. If another application needs large amounts of RAM, this is
fine, too, since the RAM is available for that purpose, too.

Only if an application does need the lagre RAM disk and lots of RAM,
you are out of luck.

In fact, one of my favourite RAM disk implementation is tmpfs from
Solaris. tmpfs lives in virtual memory and, IMHO, the best thing about
tmpfs is, that you do not have to specify any size for it. If you
store files on the tmpfs volume, they are strored in virtual memory,
if you execute large programs, VM is used for that purpose. You can
store as much data on the tmpfs, as you have virtual memory. If you
remove a file on the tmpfs volume, the virtual memory ocupied by that
file is released and can be used as main memory again.

73, Mario
-- 
Mario Klebsch                                           [EMAIL PROTECTED]

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


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