Linux-Development-Sys Digest #16, Volume #8      Wed, 12 Jul 00 15:13:18 EDT

Contents:
  Re: SIGIO (Nix)
  -ENOIOCTLCMD ([EMAIL PROTECTED])
  Re: Interrupt handling in Linux ("Nick Lahtinen")
  Re: Install new gcc (Mathias Waack)
  Re: Install new gcc (Kaz Kylheku)
  Re: keyboard with additional function keys (Frank Ranner)
  Re: SIGIO (Kaz Kylheku)
  Re: Install new gcc (Grant Edwards)
  Re: Interrupt handling in Linux (Grant Edwards)
  Battery status of cordless mouse? (Dr. Peer Griebel)
  Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC (MWRon)
  actual implementation : continuation of <are pci drivers  char drivers?> ("Peter 
Huang")
  Re: NFSRoot problems
  Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC 
([EMAIL PROTECTED])
  Re: actual implementation : continuation of <are pci drivers  char drivers?> (Grant 
Edwards)
  Version Control (Bill Waddington)
  Re: How to port MSVC++ app to Linux? (Warren Young)

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

From: Nix <$}xinix{[email protected]>
Subject: Re: SIGIO
Date: 12 Jul 2000 08:11:22 +0100

[EMAIL PROTECTED] (Kaz Kylheku) writes:

> On Thu, 06 Jul 2000 14:16:04 +0200, Benjamin Morin <[EMAIL PROTECTED]>
> wrote:
> >Hello,
> >
> >I'd like my process to be informed whenever something is written into a
> >given file. I thought this piece of code would be all right, but it
> >doesn't work... Could someone help me?
> 
> There is no notification mechanism for doing this in the POSIX interface.

I've always wondered why select() didn't do this with regular
files. Annoying.

-- 
`I can guarantee it's no problem in my network, and if I don't get some
 sleep soon, I'll guarantee it will become a problem in your network.'
     --- Chris `Saundo' Saunderson deals with a late-night phone call

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

From: [EMAIL PROTECTED]
Subject: -ENOIOCTLCMD
Date: Wed, 12 Jul 2000 14:34:20 GMT

I'm wondering about -ENOIOCTLCMD.
I wrote a device driver that returns -ENOIOCTLCMD when a program asks
for a non existent ioctl command. But strerror in that case returns
"unknown error 515" (well, in fact "erreur inconnue 515").

I checked /usr/src/linux/include/linux/errno.h where I found :

==============================================
/* Should never be seen by user programs */
#define ERESTARTSYS     512
#define ERESTARTNOINTR  513
#define ERESTARTNOHAND  514     /* restart if no handler.. */
#define ENOIOCTLCMD     515     /* No ioctl command */
===============================================

So I thought that I was returning an incorrect error code, since
ENOIOCTLCMD 'Should never be seen by user programs'.

But I gave an eye to a few drivers in linux/drivers/char, and
the ones I saw just return -ENOIOCTLCMD as I do.

So :
-> Is there something wrong about all this, and where ?


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: "Nick Lahtinen" <[EMAIL PROTECTED]>
Subject: Re: Interrupt handling in Linux
Date: Wed, 12 Jul 2000 08:38:51 -0600

Thanks for your help, I think I should be able to start to do this thing
now, as I was occupied the other day trying to get my Linux reinstalled on a
different hard drive.  The main reason I was concerned about the IO on the
port is that this program needs to handle both input and output on this
port, while assembling the data that is sent and disassembling the data that
is received, and also polling for user input from the keyboard.  I believe
there should be some delimiters in the packages that I recieve, so I should
be able to pull them off the buffer the way I want to.  Thanks again.

Nick




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

From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: Install new gcc
Date: 12 Jul 2000 16:18:47 +0200

"Chun Seong Ng" <[EMAIL PROTECTED]> writes:

> Hey Mathias, I suspect my current gcc got problem and I'm trying to
> upgrade gcc to 2.95.2 version. But the kernel still show gcc version
> is 2.91.66 after I've installed 2.95.2 version.

Installing gcc from the sources isn't an easy job (sometimes). I prefer 
installing it (and all other packages) from precompiled packages 
as rpm or deb. 

Check where the new gcc was installed and where the old gcc is 
(which gcc). Try to call the new gcc with complete path. I can't 
tell you more:(, ask in a better newsgroup for installation problems. 

And pls. don't send me email copies of your postings. 

Mathias

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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Install new gcc
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Jul 2000 14:53:32 GMT

On Wed, 12 Jul 2000 14:52:04 +0100, Chun Seong Ng <[EMAIL PROTECTED]> wrote:
>Hey Mathias,
>I suspect my current gcc got problem and I'm trying to upgrade gcc to 2.95.2
>version. But the kernel still show gcc version is 2.91.66 after I've
>installed 2.95.2 version.
>
>The following are the steps I've gone through:
>1) Extract gcc-2.95.2.tar.gz in a directory
>2) configure gcc by key in './configure'
>3) build gcc by key in 'make bootstrap'
>4) then install it by key in 'make install'
>5) and type 'gcc -v' to display gcc version
>
>There is no error prompt out during installation.
>
>my question are:
>Do I need to uninstall or delete old gcc version before I install the new
>one?

No, you can install as many gcc versions as you like. Just choose a suitable
location for them. 

The gcc, g++ and other front ends know where to locate their own files.
So the biggest concern is about where to stick the various versions of gcc.

One scheme is to change their names. E.g. have ``gcc'' be your main compiler,
and then ``gcc-2.95.2'' be the newly installed thing, etc.

It's useful, at times, to maintain multiple versions of gcc.

-- 
#exclude <windows.h>

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

From: Frank Ranner <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.development.apps,comp.os.linux.development,comp.os.linux.hardware
Subject: Re: keyboard with additional function keys
Date: Wed, 12 Jul 2000 22:52:22 +1000

LY wrote:

> Hi!
>
> Thanx for answering.
>
> The keyboard is from an unknown european company. Its name is SKIDATA.
> And I want to use this keyboard under X.
>
> CU

Try running xev. This program will show you what codes are being
generated when you press and release the keys.

Regards, Frank Ranner


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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: SIGIO
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Jul 2000 15:07:42 GMT

On 12 Jul 2000 08:11:22 +0100, Nix <$}xinix{[email protected]> wrote:
>[EMAIL PROTECTED] (Kaz Kylheku) writes:
>
>> On Thu, 06 Jul 2000 14:16:04 +0200, Benjamin Morin <[EMAIL PROTECTED]>
>> wrote:
>> >Hello,
>> >
>> >I'd like my process to be informed whenever something is written into a
>> >given file. I thought this piece of code would be all right, but it
>> >doesn't work... Could someone help me?
>> 
>> There is no notification mechanism for doing this in the POSIX interface.
>
>I've always wondered why select() didn't do this with regular
>files. Annoying.

Because the purpose is to detect whether I/O can proceed without blocking.
If you are at the end of the file, read will in fact proceed without blocking,
with a 0 result. There is no notion that the file is incomplete, and so
more data can be waited for.

Remember, even on sockets, an end of data condition results in a positive
select or poll, with a subsequent read of zero bytes. This is exactly
what happens at the end of a regular file.

The appropriate interface for multiplexing disk accesses is asynchronous I/O,
which allows the process to queue the request, and then receive a completion
notification later. This notion is general; it can be applied to any
kind of I/O.

You could define select-like semantics for disk I/O in terms of availability of
buffered data or buffer space. E.g. a read select/poll on a file could be
positive if the data on the next read can be pulled from a buffer. It could
guarantee, say, that the read will not block on the disk if it does not request
beyond the end of the current block. Likewise, a positive write select would
mean there is room to buffer at least one block of data.  This could be very
useful on NFS. A single threaded program could then use select or poll to
handle concurrent reads from multiple NFS servers.

-- 
#exclude <windows.h>

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

From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: Install new gcc
Date: Wed, 12 Jul 2000 15:31:50 GMT

In article <8kht3v$icm$[EMAIL PROTECTED]>, Chun Seong Ng wrote:

>I suspect my current gcc got problem and I'm trying to upgrade
>gcc to 2.95.2 version. But the kernel still show gcc version is
>2.91.66 after I've installed 2.95.2 version.

The kernel shows what version it was compiled with, not what
version of gcc is installed or used on the system.  If you
haven't re-compiled your kernel, the gcc version displayed by
it won't change.

If you want to know what version is being used on the current
system do:

 $ gcc --version
 
-- 
Grant Edwards                   grante             Yow!  I selected E5... but
                                  at               I didn't hear "Sam the Sham
                               visi.com            and the Pharoahs"!

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

From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: Interrupt handling in Linux
Date: Wed, 12 Jul 2000 15:35:45 GMT

In article <[EMAIL PROTECTED]>, Nick Lahtinen wrote:

>Thanks for your help, I think I should be able to start to do
>this thing now, as I was occupied the other day trying to get
>my Linux reinstalled on a different hard drive.  The main
>reason I was concerned about the IO on the port is that this
>program needs to handle both input and output on this port,
>while assembling the data that is sent and disassembling the
>data that is received, and also polling for user input from the
>keyboard.  I believe there should be some delimiters in the
>packages that I recieve, so I should be able to pull them off
>the buffer the way I want to.  Thanks again.

It sounds like you should be using one or more of:

  * multiple threads
  * multiple processes
  * poll()/select() [I forget which one is in fashion these days].

Which one[s] to use is not easy to decide without detailed
knowlege of the application.  Even then, one often gets 90% of
the way through the design before figure out one has headed
down a sub-optimal path.

-- 
Grant Edwards                   grante             Yow!  What I want to find
                                  at               out is -- do parrots know
                               visi.com            much about Astro-Turf?

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

From: [EMAIL PROTECTED] (Dr. Peer Griebel)
Subject: Battery status of cordless mouse?
Date: Wed, 12 Jul 2000 16:02:54 GMT

Hi,

I just bought a Logitech cordless wheel mouse. Is there anybody who
knows the protocol of this mouse? I would like to know about all
features: the core ps/2 protocol and the extensions e.g. to read the
battery status.

The web pages of Logitech don't tell anything about it. So where can I
get help?

Thank you.
  PG.

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

From: [EMAIL PROTECTED] (MWRon)
Crossposted-To: comp.os.linux.powerpc
Subject: Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC
Date: Wed, 12 Jul 2000 11:37:47 -0400

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:

I appreciate those that have found my posting useful, and I apolgoize to
those that felt it was abusive.

>The fact that the Linux _kernel_ is pretty strongly tied to GCC suggests
>to me that comp.os.linux.development.apps would be a more appropriate
>venue than comp.os.linux.development.system, but people are clueless
>enough about what belongs here that that doesn't strike me as a _big_
>problem...

the next generation of CodeWarrior for Linux will continue to use GCC
plugins, but maybe with the addition of Java tools I can see where the
comp.os.linux.development.apps would have been more appropriate.

Again I apologize if I offended anyone it was not meant to be any
commercial posting.

Ron

-- 
Metrowerks acquires HiWare AG to be European headquarters
http://www.metrowerks.com/news/hiware/

Metrowerks, a Motorola Company   -  Ron Liechty
"Software Starts Here"  -  [EMAIL PROTECTED]

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

From: "Peter Huang" <[EMAIL PROTECTED]>
Subject: actual implementation : continuation of <are pci drivers  char drivers?>
Date: Wed, 12 Jul 2000 09:57:06 -0700

Thank you all for replying.

I'm now not sure about the type of device driver to register my PCI driver.

First of all, it communicate with a peripheral card through its share memory
and through a draw bridge. Secondly, the share memory would be manage
by a simple memory manager that I'm going to create. There will be some data
structure read/write through the memory. It would be of small sizes. (less
than 100 bytes)
However, here is  the confusing. It would also support DMA that read
memory in blocks. Seems like the inclusion of this capability would make
this a block driver. So it would contain both the block and char ability.
I'm also not sure about splitting up the driver into two because these two
capabilities are intertwine. Would any one have any suggestion on this
scenario and
how should I register the driver.

Peter


>> A PCI driver which drives a PCI modem card is a char device. A
>> PCI driver which drives a network card is a network device. A
>> PCI driver that would offer a disk drive to the system (e.g. a
>> software/hardware PCI RAID device) would be a block device. A
>> SCSI PCI board is a SCSI ha.

>you shouldn't mix up things like this. Character drivers and
>block drivers have their special meanings in the kernel. A SCSI
>or Network driver has only a meaning of functionality.

Wrong.  SCSI and network drivers are neither char nor blockdrivers.  They
are network and SCSI drivers.

Network devices (e.g. eth0, eth1) are created "on the fly" as
needed and don't live in /dev like normal char and block
devices.  The interface to a network devices/drivers is also
not the same as for a "normal" block or char driver.

>A SCSI driver will usually be a character driver, which means
>that data is written/read character wise buit a filesystem
>will be a block device where write/read will be performed in
>blocks of a certain size.

You have correctly differentiated char and block devices. Block
devices (e.g. disks) transfer data in fixed sized blocks. Char
devices (e.g. serial ports, printer ports, etc.) model a device
as a stream of bytes.

However, the part about a SCSI driver being a char devices
isn't correct. A SCSI driver (for a PCI board, which is what
we're talking about) is a different animal that is neither a
char nor block device.  It's a low-level layer that sits
underneath the "generic" SCSI layer, which in turn sits
undernead both char device drivers (e.g. st) and block device
drivers (e.g. sd).




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

From: <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,linux.dev.kernel
Subject: Re: NFSRoot problems
Date: 12 Jul 2000 17:05:48 GMT

In comp.os.linux.development.system Krik Lee <[EMAIL PROTECTED]> wrote:
> Hi:

>   I am trying NFSRoot in 2.4.0-test2-ac1.

do you need a 2.4.0-test kernel?

use a 2.2.x kernel if not

maybe you should also report this to [EMAIL PROTECTED]

with a _full_ description (hardware/network/nfsroot config)

                Debian/GNU Linux: a dream come true
=============================================================================
"Computers are useless. They can only give answers."            Pablo Picasso

--->    Visita http://www.valux.org/ para saber acerca de la    <---
--->    Asociaci�n Valenciana de Usuarios de Linux              <---
 

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

From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.powerpc
Subject: Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC
Date: Wed, 12 Jul 2000 17:57:59 GMT

In comp.os.linux.development.system MWRon <[EMAIL PROTECTED]> wrote:

| I appreciate those that have found my posting useful, and I apolgoize to
| those that felt it was abusive.
|
|>The fact that the Linux _kernel_ is pretty strongly tied to GCC suggests
|>to me that comp.os.linux.development.apps would be a more appropriate
|>venue than comp.os.linux.development.system, but people are clueless
|>enough about what belongs here that that doesn't strike me as a _big_
|>problem...
|
| the next generation of CodeWarrior for Linux will continue to use GCC
| plugins, but maybe with the addition of Java tools I can see where the
| comp.os.linux.development.apps would have been more appropriate.

Is this an assumption that all apps have to be done in Java?  What about
those who code in C?

I was also going to ask why there is no support for Slackware?

-- 
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil  (at)  ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]

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

From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: actual implementation : continuation of <are pci drivers  char drivers?>
Date: Wed, 12 Jul 2000 18:20:01 GMT

In article <8ki98g$lcn$[EMAIL PROTECTED]>, Peter Huang wrote:

>I'm now not sure about the type of device driver to register my
>PCI driver.
>
>First of all, it communicate with a peripheral card through its
>share memory and through a draw bridge.

Don't know what a draw bridge is...

>Secondly, the share memory would be manage by a simple memory
>manager that I'm going to create. There will be some data
>structure read/write through the memory. It would be of small
>sizes. (less than 100 bytes)

When you talk about reading stuff through memory are you
talking about the interface between the board and the driver or
between the user and the driver?  The char vs. block difference
is in the interface between the user (including the kernel) and
driver.

It's got little to do with the physical interface used by the
driver to manipulate the board.

>However, here is the confusing. It would also support DMA that
>read memory in blocks. Seems like the inclusion of this
>capability would make this a block driver. So it would contain
>both the block and char ability.

If you want, you can have a single driver that impliments
multiple devices block and char both.  (Doing that is probably
more complicated, and you probably don't need to do that.)

>I'm also not sure about splitting up the driver into two
>because these two capabilities are intertwine. Would any one
>have any suggestion on this scenario and how should I register
>the driver.

Do the following to operations make sense?

    Write this data to block number 19834.
    Read block number 8719.

If yes, and those are the primary ways somebody uses the
device, and blocks are always the same size, then it should
probably be a block device.

If the blob of data managed by the driver isn't randomly
accessible (you can't at any point in time read/write any block
you want), then it should probably be a char device: when you
read you get the "next" bytes in the stream, and when you write
you always write to the end of a "stream" of bytes.

For the miscellaneous control/configuration/setup/status stuff
you can define ioctls that use whatever data structures you
want. For a char device you can also define ioctl() calls that
modify where data goes to/from, so that you get some of the same 
seekability of a block device.

Are there any existing drivers for similar devices?  What do
they do?

-- 
Grant Edwards                   grante             Yow!  Are you mentally here
                                  at               at Pizza Hut??
                               visi.com            

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

From: Bill Waddington <[EMAIL PROTECTED]>
Subject: Version Control
Date: Wed, 12 Jul 2000 18:42:50 GMT

Hello All,

Can someone point me at a software version control utility/reference?  I
need to do a better job of organizing my Solaris, HPUX, and Linux
drivers by version (both OS version and driver version).

Trying to teach an old dog _old_ tricks.

TIA
Bill


--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Date: Wed, 12 Jul 2000 13:03:04 -0600
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: How to port MSVC++ app to Linux?

Dima Maziuk wrote:
> 
> >Perhaps Microsoft may one day decide to port MFC
> > to Linux; we will then have all the Microsoft apps we can handle!
> 
> Dear God please no.  :)

Not to worry.  MFC is intimately aware of the Win32 architecture.  To
port it to Xlib or some other X-based UI system, they'd end up doing
like they did with the Mac port of MFC: emulating Win32 with local
mechanisms for the benefit of MFC.  We all saw how successful Mac MFC
was....

As for Visual C++ generating nonportable code, my question is, if you're
trying to do something uncommon (e.g. "write portable code"), why are
you using a code generator?  Just because AppWizard generates code that
mixes UI and "business logic" doesn't mean Visual C++ is totally
useless.  You just have to take a few matters into your own hands.

I've got several modules I use in my programs that are portable between
Visual C++ and Linux/GNU g++, and several more that are portable between
Borland C++/OWL and Visual C++/MFC.  It's not that hard, guys.
-- 
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
= 
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

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


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