Linux-Development-Sys Digest #184, Volume #7 Sat, 11 Sep 99 23:13:43 EDT
Contents:
Re: graphical debugging, development environments? ("Frank V. Castellucci")
Linux Equiv (Bitware/Supervoice) (Matt)
Re: How do you revert from Afterstep to KDE?
Re: pci libraries (Peter Samuelson)
Re: Lexmark Printer (Peter Samuelson)
vgetty and 3com message modem ext (Matt)
Re: threads (David Schwartz)
Re: Figure Out The MS Source Code Yourself (Phil Hunt)
Re: development gui's for linux (Peter Samuelson)
Re: Generating a configuration file for an existing binary kernel (Peter Samuelson)
Re: graphical debugging, development environments? (David Frantz)
----------------------------------------------------------------------------
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: graphical debugging, development environments?
Date: Sat, 11 Sep 1999 17:18:24 -0400
Jason Rosenberg <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> My previous post entitled "development gui's for linux"
> seems to have been misinterpreted, so I'll try again...
>
> I am interested in knowing about the various integrated
> compiling/debugging environments with graphical interfaces available
> for linux, either free or otherwise. CodeWarrior? GNU?
>
> I am also interested in those that exist for multiple architectures,
> such as Intel, Alpha, SPARC, etc.
>
I use SlickEdit for Linux which interfaces to RCS for project management.
It is not a IDE in the sense of something like VisualAge from IBM.
For debugging I use DDD (it is the only one worthy of mentioning IMHO). DDD
works on top of gdb (GNU debugger).
To hook DDD to Slick I just set the Debugger program properties in the
project I am working on.
Frank V. Castellucci
------------------------------
From: Matt <[EMAIL PROTECTED]>
Subject: Linux Equiv (Bitware/Supervoice)
Date: Sat, 11 Sep 1999 22:21:32 +0100
Hi,
Is there a linux equivelent to Windows Bitware's and Supervoices
telephone message/routing applications.
I am getting fed up trying to get winNT to work with Bitware and
Supervoice. I use Linux a lot and it is far better, but I am
unaware of any equivilent applications.
Are there any ?
Many thanks
Matt
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.alpha,comp.os.linux.development.apps
Subject: Re: How do you revert from Afterstep to KDE?
Date: 11 Sep 1999 21:10:29 GMT
On Sat, 11 Sep 1999 16:43:55 +0200, Arnoud de Geus <[EMAIL PROTECTED]> wrote:
>
>Revert to GNOME. Isn't that a much better idea?
>
Flame me if I'm wrong, but isn't GNOME an environment while AfterStep
is a window manager? If you run GNOME without a window manager, your
windows will just sit there doing nothing because nothing is managing them.
Robert
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: pci libraries
Date: 11 Sep 1999 17:38:33 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Chris Naylor <[EMAIL PROTECTED]>]
> I have a problem that I'm sure has a very simple answer
Yes and no.
> I am developing a device driver for a pci interface card. As a
> result I am using functions in the pci.h header. My problem is that
> I don't know which libraries to include for these functions - in
> fact, I can't even find the file where these functions are
> implemented.
If you are writing a kernel-mode device driver, the functions will be
exported directly by the kernel and your module will be linked with the
running kernel image when it is loaded by `insmod'.
Implementation is in the kernel source code. Look under
`drivers/pci/'.
The reason I said "yes and no" is because although the immediate answer
is rather simple, the question reveals that you most likely have a lot
to learn about how drivers work -- kernel images, loading and unloading
modules, exported symbols, execution contexts, available "library
functions" (this ain't libc, folks), the user-mode interfaces, the
kernel-mode interfaces, SMP-safe coding ... scores, nay, *hundreds* of
details on the above and more.
Alternatively I may have it all wrong and you're trying to write an
ordinary user-mode program which happens to drive a PCI device. In
that case, the answer to your original question is: those functions are
*not* directly available in any library; they work in kernel mode only.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Lexmark Printer
Date: 11 Sep 1999 17:29:06 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Ricky Duke <[EMAIL PROTECTED]>]
> Is their anyway I can get my Lexmark 5700 printer to work under Linux 6.0?
When did Linux make it to version 6.0? I downloaded 2.3.18 this afternoon.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Matt <[EMAIL PROTECTED]>
Subject: vgetty and 3com message modem ext
Date: Sat, 11 Sep 1999 23:11:27 +0100
Hi,
Does the 3com message modem external work with
mgetty/vgetty and ZyXEL software under SuSE 6.1 ?
Is it easy to configure/build ?
Many thanks
Matt
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: threads
Date: Sat, 11 Sep 1999 16:10:57 -0700
Joseph H Allen wrote:
> > 1) We have to gather together everything we might ever wait for in one
> >place. And if we ever have to wait for something we can't 'select' on,
> >such as disk I/O, we're in trouble.
>
> One cheesy solution to the disk I/O problem is to use a seperate thread or
> process for just disk I/O, and have it send a message to the process with
> the big select() when it's complete. Supposedly Solaris uses kernel threads
> in just this way to hack non-blocking disk I/O onto the system.
It's cheesy, however, because it breaks the "any thread can do any
task" design model. As a result, if you want to switch from doing disk
I/O to doing something else, you incur a context switch. There's no
special reason to use separate threads for this.
> > 3) We have to keep 'saving our place' to go back to it. We can't easily
> >use the stack to keep track of what we're doing (as most progams do).
>
> You can have multiple stacks in a cooperative user-space multi-threading
> environment. Basically this means that thread switching only happens during
> I/O waits and never preemtively by the kernel. It's nice because you almost
> never have to use any more locks than you would in the normal event-driven
> I/O model. I have written a widget library for X which uses this technique:
> see ftp://ftp.worcester.com/pub/joe/notif-0.2.tar.Z
Yes, but you really want to avoid having a particular request 'sitting
on' a particular stack. You'd rather it be in a shared job queue. In a
job queue, any thread that happens to be running can grab it -- thus no
context switch. In a stack, that particular thread has to start running
to do that job.
Now it's true that a user-space threading model makes such context
switches less expensive, but it's still nicer to avoid them when you
can. You can also do this with setjmp/longjmp type things, but it tends
to be uglier than other possible solutions.
> > I hope this makes the point more clear. Rather than comparing threads
> >to a 'one process per connection' model, compare it to a 'one process
> >for everything' model. Then look at how it solves the problems with that
> >architecture without imposing too many penalties of its own.
>
> One problem with the one thread per conenction model is that you may have
> 100s of clients that are doing nothing most of the time, and each operating
> system thread takes up a lot of stack space. For example, the default stack
> may be 1MB- you can then have only 2000 connections before you run out of
> memory (or maybe worse, given whatever kernel resources are taken by the
> threads).
Exactly. Plus anytime you switch from handling connection X to handling
connect Y, you force a context switch. This is _not_ what threads are
for.
> It would seem that you really want threads for making best use of
> the available CPU power, and not for code structuring. Perhaps you have one
> thread for quick I/O processing feeding a pool of threads which do the
> actual work (perhaps each thread does a single transaction). Depending on
> the nature of the work, the pool would consist of maybe 3 or 4 threads per
> actual processor.
There's no special reason to have one thread doing the quick I/O
processing and a pool of other threads doing the actual work. One thread
is as good as another. With this approach, you require a context switch
every time you change from I/O processing to doing work.
I must admit, it frequently winds up being convenient to do just this,
but it really is more elegant to have a 'any thread can do any job'
model. This way, you are never forced to have a context switch unless a
shared resource is contended for, an I/O operation blocks, or a blocking
I/O operation completes.
I've also found that this approach minimizes the number of threads not
waiting for a job. This reduces the chance that resources will be
contended for. We all know that mutexes and condition variables are much
cheaper when they don't actually suspend or wake any threads. This
allows you to have very few threads doing anything but waiting for work,
holding no shared resources.
DS
------------------------------
From: [EMAIL PROTECTED] (Phil Hunt)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Figure Out The MS Source Code Yourself
Date: Sat, 11 Sep 99 15:38:23 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] "David Frantz" writes:
> You have to be very carefull now a days with recieving RF
> transmissions. We in the USA are now in the unique position of sharing
> a law that make the reception of radio signals from Cell Phones a
> crime. The only other country that we share such a law with is North
> Korea, really make you wonder!
>
> Also the FCC, under pressure from the FBI, CIA, NSA and other goverment
> organizations, to restrict what you can listen to. The FCC was also
> just recently forced to change its Cell Phone regulations to require Cell
> Phone companies to provide tracking capabilities. This is so Big
> Brother will always know were you are.
In the light of things like this, I find it surprising that anyone
doubts that the NSA might force Microsoft to put a backdoor in
Windows.
--
Phil Hunt - - - - - - - - - [EMAIL PROTECTED]
- Linux will be 8 years old on 17th September! See: -
http://www.vision25.demon.co.uk/prog/linuxbirthday.html
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: development gui's for linux
Date: 11 Sep 1999 20:02:28 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Jason Rosenberg <[EMAIL PROTECTED]>]
> I am wondering what is involved with porting software to linux?
The UUPP (Unix-to-Unix Porting Problems) of yesteryear are pretty much
gone: bzero versus memset, usleep versus select, whether signal
handlers are void or int, whether the compiler knows about (void*) or
you have to use (char*), how to read directories, which header files
have string functions and time structs, all those mundane things you
find in autoconf macros the world over. Today we have ANSI C and POSIX
and plenty of compatibility functions and _*_SOURCE macros and as long
as you code to the standards your code will be well-liked by compilers
and libraries across most modern Unix platforms including Linux and
glibc. Now, it happens that very little software in the world adheres
strictly to POSIX and ANSI C, so any of your little deviations may come
back to haunt you. A well-known example: you cannot free() something
twice. This was never legal but many older libc's out there didn't
seem to mind.
I have been assuming you are talking about porting C. Other languages
may differ.
> First, I imagine there are a few good gui based development
> environments for linux, can someone provide recomendations? I am
> interested in both commercial packages and free packages.
Mmmm, I always use xemacs, gcc, make and gdb. Not perfect by any
means, but they are of course free for personal use, free for
noncommercial use, and free for commercial use. xemacs is not an IDE,
exactly, but it has some aspects of one, i.e. automatic code
indentation and color syntax highlighting, ability to run the debugger
and the compiler in sub-windows, symbol cross-referencing.
Metrowerks CodeWarrior is probably the best-known commercial IDE for
Linux. I don't know much about it, or about the many free projects out
there in various stages of usability/completeness to much the same end.
> I am also interested in the various available compilers available
> (whether or not they are tied to any gui development environments).
The CodeWarrior compilers will soon be shipped if they haven't been
already (Metrowerks originally shipped only the IDE portion of their
product, not the compilers and debuggers). But most Linux people use
GCC (the GNU Compiler Collection) which are universally available,
provide solid ISO C and C++ implementations (keeping up as best they
can with the C++ standard) and offer many useful though nonportable
extensions, along with the benefits of standardization across
platforms: uniform (and high-quality) error messages, uniform
command-line switches, etc.
If you want really good code generation on PowerPC, it is said that the
CodeWarrior compiler is the ticket. And if you want really good code
generation on Alpha, the DEC^H^H^HCompaq C compiler (just released in
beta, I believe) has that reputation. Neither is as free or as
standard as GCC, though.
> Also, are there any that are seemless across the different CPU's
> supported by linux, such as Intel, Alpha and SPARC? Can source code
> be considered source code compatible between each of these? I would
> imagine the 64-bit issues of Alpha might be something of an issue.
As I said, GCC is the de facto standard Linux compiler collection. In
general, standardization of the programming interface is extremely good
between Linux platforms, so long as you're using the same version of
libc on all of them (glibc 2.1.2 is current as of this writing; for
these purposes, consider any glibc 2.1 release to be an identical API,
and glibc 2.0 has less but no real *different* functionality).
You are right that 64-bit pointers and long integers creates a
portability problem with Alpha (and UltraSPARC and soon Merced), but of
course nobody with Good Coding Habits makes silly assumptions like
sizeof(long)==sizeof(void*)==32, right? Also note that some Linux
platforms (SPARC/UltraSPARC, PowerPC, m68k) are big-endian and some
(ARM, Intel, Alpha, Merced) are little-endian, and don't forget MIPS
and SuperH which can be configured either way. (Linux also supports
PDP-endianness, if only jokingly.) As long as your code doesn't delve
into low-level functionality to the point of, say, assuming that
there's a PCI bus, the main portability problems you have are
sizeof(long), endianness and the age of the libc release (which, people
will tell you, *can* cause major porting headaches, depending on your
standards-conformance habits).
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Generating a configuration file for an existing binary kernel
Date: 11 Sep 1999 20:17:30 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Chris Cowan <[EMAIL PROTECTED]>]
> Is there a tool or technique capable of generating the kernel
> configuration file given a binary kernel from a 3rd party, and the
> appropriate source tree?
Well you could boot the kernel and empirically test for every last
feature. Not sure if that would be possible for *everything* or only
for most options, and it probably would not be practical. You could
get a hint on major features by reading /proc/ksyms which are exported
symbols, and other /proc files for driver/filesystem availability.
> How difficult do think it would be to write one? I think of several
> uses for such an animal.
If you can control the third-party kernel source tree (to the extent of
inserting a patch in it), the animal has already been written. Long
long ago in days of yore (i.e. kernel 2.2.4 or so) someone hacked up a
/proc/.config which stores and yields a copy of the original .config
file. I modified this to store /proc/.config.gz instead on the theory
that making the user type zcat instead of cat is worth the extra page
or two of unswappable kernel memory. Email me if you are interested; I
can easily dig up my version of the patch, clean it up a bit and send
it to you.
(My original plan was to make the .config.gz __initdata, copy it to a
dynamic buffer and allow the user to free up the space by removing the
file, but /proc doesn't directly support unlink() and I lost interest
before getting any substitute semantics right.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: David Frantz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: graphical debugging, development environments?
Date: Sun, 12 Sep 1999 01:59:47 +0000
Reply-To: [EMAIL PROTECTED]
Jason Rosenberg wrote:
> My previous post entitled "development gui's for linux"
> seems to have been misinterpreted, so I'll try again...
>
> I am interested in knowing about the various integrated
> compiling/debugging environments with graphical interfaces available
> for linux, either free or otherwise. CodeWarrior? GNU?
>
> I am also interested in those that exist for multiple architectures,
> such as Intel, Alpha, SPARC, etc.
>
> Thanks,
>
> Jason
Hi Jason;
I can't say that I've had a lot of ecperience with unix GUIs however I
have used Visual Studio some. If you understand that I consider Visual
Studio one of MS better products ( This doesn't mean I like thier brain
dead compiler) then you will understand what I'm looking for.
I have tried several differrent editors or developement systems for
Linux. I will try to describe what I've found so far.
GVIM and Grasp are two editors you should always have around. The nice
thing about GVIM is that its very flexible, I was able to create a
syntax file for an embedded controller in no time at all. Grasp can be
very useful in quickly understanding someone elses C/C++ code.
Niether of these is a complete system that you are looking for.
I've tried several GUI interfaces for LINUX developement that you seem
to be interested in. the offerings for both KDE and gnome can't even
be considered useful right now. After a couple of months down time
and a few reccomendations online I looked at "CODE CRUSADER 2.1.3",
which you can get from www.cco.caltech.edu/jafl/jcc/. I just recently
got jcc (code crusader) to compile and I must say I'm impressed!
Jcc uses a GUI library that is differrent that either KDE or GNOME so
thats something to consider. I can't say that I'm a C++ expert but the
software appears to be very well written. What I haven't checked out
yet that you may want to consider looking at is the integration of a GUI
for debugging. I haven't installed this so yo may want to consider
it. Using jcc won't get you completely away from make and make files,
I had to edit one that jcc created for a hello world type test, so don't
gets your hopes up. This problem could be the result fo being a very
new user to the program.
Thanks
Dave
------------------------------
** 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
******************************
