Linux-Development-Sys Digest #293, Volume #6 Sun, 17 Jan 99 06:14:37 EST
Contents:
Driver Development HELP - skbuffs (Mike Ireton)
Re: File descriptor as array index? (sherle)
Re: disheartened gnome developer (Navindra Umanee)
Re: How to find lost ext2 partitions (Peter Samuelson)
Re: disheartened gnome developer (Perry Pip)
Re: things I'd pay to have developed for Linux... (Peter Samuelson)
Re: Resuming a program execution after SIGSEGV excep. (Bjorn Reese)
Re: disheartened gnome developer (Christopher B. Browne)
Re: Adopting COM? (Christopher B. Browne)
Re: disheartened gnome developer (steve mcadams)
----------------------------------------------------------------------------
From: Mike Ireton <[EMAIL PROTECTED]>
Subject: Driver Development HELP - skbuffs
Date: Sun, 17 Jan 1999 06:46:17 +0000
Reply-To: [EMAIL PROTECTED]
Howdy,
I've been hacking together a device driver as a loadable module and
I have most everything working. I have a situation where I would like to
maintain a list of sk_buff's as handed to me by the kernel, and then
from within a bottom half handler, traverse the list of skb's with a
pointer and selectively pull them out of the list.
I see that there is the functions skb_dequeue() which will take it
off the head of this list. What I want is a way to generate a pointer to
the list and then traverse it and test each skb in that list for certain
conditions, and if true, to remove that skb from the list. What
functions, if any, are available to me to do this?
Mike-
------------------------------
From: sherle <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: File descriptor as array index?
Date: Tue, 12 Jan 1999 11:57:02 -0600
Why not a second level indirection?
Use an internal array (0..n) for storing the sockets or file
descriptors. In functions requiring the actual OS descriptor, deference
the array.
If the number of descriptors you are dealing with is small, you may not
pay too much penalty; certainly less than a "general" hash table. You
recognize of course, that what I just proposed can also be viewed as a
hash table?
To illustrate, instead of:
===
fd = open (filename, mode);
read (fd, ...);
===
Use:
===
fd = map(open (filename, mode));
read (unmap(fd), ...);
===
Where map() and unmap() could be macros or actual function calls
depending on how smart you want them to be.
e.g.,
#define map(n) (Small_array[Num_fd] = n, Num_fd++)
#define unmap(n) Small_array[n]
The macros I have written are just for illustration. You may want to
suitably parenthesize etc.
/sudhi.
Roy Stogner wrote:
>
> I'm writing a TCP server class library for Unix (specifically Linux,
> but I'd like it to be portable), and I've run into a problem:
>
> I need to be able to associate various bits of data (most importantly
> a functor or function pointer) with each active file descriptor being
> sent to select(); I can put this in a hash table if necessary, but it
> would be nice to just maintain a vector of the data, and use the file
> descriptor as an index into that vector.
>
> For all the programs I've used and strace'd, this would work
> perfectly, since the programs get assigned nice, low file descriptors
> to use - however that doesn't seem to be guaranteed anywhere. This
> server will have ~50 simultaneous clients, and if all of those sockets
> had file descriptors less than 500, I would be happy. If one of those
> sockets was assigned an fd of 50000, I would need to allocate a lot of
> wasted memory, and would be very unhappy.
>
> Does anyone know how file descriptors get assigned under Linux and
> other Unices? Would it be safe to use them in this fashion?
>
> Replies cc:'ed to roystgnr @ rice.edu would be appreciated.
> ---
> Roy Stogner
------------------------------
From: Navindra Umanee <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 16 Jan 1999 08:06:53 GMT
Perry Pip <[EMAIL PROTECTED]> wrote:
> Yes it gives you a way but not the best way. Are you talking about
> "inerest in C" in the context of just Qt programmers or in the context of
> all toolkit programmers. In the context of all toolkit programmers there's
> plenty of interest in c, but I wouldn't expect to find such interest in
> the Qt community.
Toolkit programming in C seems to be really ugly. (see code below)
Why would people want to use C for that when it's so much cleaner in
C++? (or maybe it's just Qt that's magic)
> Well I can say many people are coding away in Gtk. (Which I should be
> doing right now, instead of wasting my time in this thread.)
In C?
Here're some example programs I'd like to quote again:
==========
/*
* helloworld.c for GTK+ from
* http://www.gtk.org/tutorial/gtk_tut-2.html#ss2.1
*
* It does make for a pretty straightforward read but writing is another
* matter.
*/
#include <gtk/gtk.h>
void hello (GtkWidget *widget, gpointer data)
{
g_print ("Hello World\n");
}
gint delete_event(GtkWidget *widget, GdkEvent *event, gpointer data)
{
g_print ("delete event occurred\n");
return (TRUE);
}
void destroy (GtkWidget *widget, gpointer data)
{
gtk_main_quit ();
}
int main (int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_signal_connect (GTK_OBJECT (window), "delete_event",
GTK_SIGNAL_FUNC (delete_event), NULL);
gtk_signal_connect (GTK_OBJECT (window), "destroy",
GTK_SIGNAL_FUNC (destroy), NULL);
gtk_container_border_width (GTK_CONTAINER (window), 10);
button = gtk_button_new_with_label ("Hello World");
gtk_signal_connect (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (hello), NULL);
gtk_signal_connect_object (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (gtk_widget_destroy),
GTK_OBJECT (window));
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (button);
gtk_widget_show (window);
gtk_main ();
return 0;
}
==========
/*
* helloworld.cc for Qt from http://www.troll.no/qt/t1.html
*
* This is too easy.
*/
#include <qapp.h>
#include <qpushbt.h>
int main( int argc, char **argv )
{
QApplication a( argc, argv );
QPushButton hello( "Hello world!" );
hello.resize( 100, 30 );
// I added this to even out the comparison with the GTK snippet.
QObject::connect( &hello, SIGNAL(clicked()), &a, SLOT(quit()) );
a.setMainWidget( &hello );
hello.show();
return a.exec();
}
==========
-N.
--
"These download files are in Microsoft Word 6.0 format. After unzipping,
these files can be viewed in any text editor, including all versions of
Microsoft Word, WordPad, and Microsoft Word Viewer." [Microsoft website]
< http://www.cs.mcgill.ca/~navindra/editors/ >
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: How to find lost ext2 partitions
Date: 16 Jan 1999 04:00:52 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Yann Dupont <[EMAIL PROTECTED]>]
> Hello. I have a problem : I have two disks where the partition tables have
> been erased by error (human error :)
>
> The ext2 partitions haven't be damaged - or the damage is minimal.
Some time ago Gordon Chaffee (author of Linux support for such things
as vfat and fat32) announced a utility to do exactly this. Look for
details on
http://bmrc.berkeley.edu/people/chaffee/fat32.html
If HTTP is inconvenient, just get the file via FTP:
bmrc.berkeley.edu:/pub/linux/rescue/fixdisktable-0.*
fat32.html makes no mention of swap partitions. I do not know whether
fixdisktable can cope with a disk that has swap partitions (or any
other type it doesn't know about). It claims to understand FAT16,
FAT32, NTFS, BSD UFS, BSD disklabels, and of course ext2.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Perry Pip)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jan 1999 10:32:42 GMT
On 16 Jan 1999 08:06:53 GMT, Navindra Umanee <[EMAIL PROTECTED]> wrote:
>Perry Pip <[EMAIL PROTECTED]> wrote:
>> Yes it gives you a way but not the best way. Are you talking about
>> "inerest in C" in the context of just Qt programmers or in the context of
>> all toolkit programmers. In the context of all toolkit programmers there's
>> plenty of interest in c, but I wouldn't expect to find such interest in
>> the Qt community.
>
>Toolkit programming in C seems to be really ugly. (see code below)
Look at what the code is doing!! The GTK helloworld is showing four
examples of it's callback mechanism.The Qt example only one. And the GTK
example shows how to write your own callbacks. The GTK example is
demonstating more functionality, i.e how to capture a wm delete event, and
how to emit a signal to another widget.
>Why would people want to use C for that when it's so much cleaner in
>C++? (or maybe it's just Qt that's magic)
That's an opinion. I don't think the signal slot mechanism in qt, which is
not standard C++ syntax, is very clean either. At least the structures and
casting in Gtk is standard C syntax. Both have learning curves.
>> Well I can say many people are coding away in Gtk. (Which I should be
>> doing right now, instead of wasting my time in this thread.)
>
>In C?
Take a look at the Gtk and Gnome apps lists and you'll see that
plenty of people are coding in C. The other GTK/Gnome bindings will have
their day when they are more mature.
>Here're some example programs I'd like to quote again:
You can't compare two tookits by just pasting in helloworlds. You'll have
to go into more depth than that, and unserstand thoroughly what the code
is doing so you don't miss out on what's in the code.
Perry
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To:
comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: things I'd pay to have developed for Linux...
Date: 16 Jan 1999 07:36:04 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Leslie Mikesell <[EMAIL PROTECTED]>]
> I'd like to see a filesystem that let your logical mount point be a
> read/write overlay of a read-only mount, possibly NFS or CDROM.
I saw a patch for this once. Don't remember what it was called, maybe
ovlfs or something. Look around places like linuxmama. I don't
remember if it was a generic VFS thing or if it was specific to CDROMs
(or isofs, to be exact) since that is what it was designed for.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Bjorn Reese)
Subject: Re: Resuming a program execution after SIGSEGV excep.
Date: 16 Jan 1999 13:51:43 GMT
Peter Samuelson ([EMAIL PROTECTED]) wrote:
> I'm not a threads guy. So, out of curiosity, what is async-safe? Is
> it anything like reentrant? (I think I understand the difference
> between mt-safe and reentrant -- has to do with deadlocking, yes?)
Async-safe means that the function is safe to call from a signal handler.
This also means that it will not deadlock.
I do not know which Linux man page contains this information, but on
Solaris it is described under 'man attributes' (can be found through
docs.sun.com)
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jan 1999 15:20:00 GMT
On 16 Jan 1999 10:46:05 GMT, Richard Kulisz <[EMAIL PROTECTED]> posted:
>In article <77h02n$bg6$[EMAIL PROTECTED]>,
>Christopher Browne <[EMAIL PROTECTED]> wrote:
>>None of those things represent "communism."
>
>Oh, but they do.
>
>>Communism has to do with doing things specifically for "the common
>>good."
>>
>>If I *enjoy* playing a sport, playing music, singing, or whatever, my
>>engaging in such activities is not "communistic." I do these sorts of
>>things because *I find it beneficial.*
>
>What you feel or do not feel is entirely irrelevant since other people
>do not have access to your feelings, and those other people matter a
>whole lot more than you do.
They don't necessarily matter in my decision to engage in the activities.
>From their point of view, the only important
>thing is that you *do* in fact accomplish something that benefits the
>whole community far *far* more than it benefits you. Then it's communism.
How can they evaluate the value of these things?
- There is no objective value to the community of my playing on a volleyball
team.
- And, by the same token, if I help run a stock exchange, thereby
establishing monetary values on a diverse grouping of capital assets, this
is likely to earn me a living, whilst accomplishing something that benefits
the community *far* more than it benefits me. You'd call *that*
communism?!?
- Evidently, according to your criterion, the only way a President of the
United States can be truly successful is by implementing communism. A
successful President should cause there to be economic growth in the the US
that far, far exceeds the few hundreds of thousands of dollars that (s)he is
likely to earn in the job. Obviously a case of accomplishing something
that, in your words, "benefits the whole community far *far* more than it
benefits you."
- Closer to home, if Paul Martin Jr. is successful in his job as Minister of
Finance, this benefits Canadians hopefully to the tune of billions of
dollars in improved allocation of resources. One would hope that this
exceeds the cost of his compensation package. (Was there a private member's
bill raising ministerial salaries into the billions?) Is that communism?
(Is Carleton U still "Last Chance U?")
>Motivation is irrelevant, only the objective actions of the system are
>relevant. A system can be communistic just as easily by bribing everyone
>into doing what is good for the community as by educating everyone into
>doing the right thing.
Ah. You must be one of the disciples of "objective value." Unfortunately,
there is reasonable evidence that there's no such thing, or at least, it's
not measurable. Things have different values to different individuals for
different reasons. Value is perceived by participants, and we don't
necessarily ever see the "objective actions of the system."
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/canada.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Adopting COM?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jan 1999 15:19:58 GMT
On Mon, 11 Jan 1999 00:33:27 +0100, Osvaldo Pinali Doederlein
<[EMAIL PROTECTED]> posted:
>>At this point, *all* the ORBs for Linux are too immature to be treated
>>as critical system facilities for anything that's critical.
>
>I was thinking about that. Maybe all you need is a standard procedure so
>any ORB can be plugged in the OS.
That's not a problem. Linux knows how to run multiple programs.
ORBs are programs. Ergo, Linux knows how to run multiple ORBs.
>distributions can also get all free ORBs included on it, since there's
>plenty space in CD-ROM distributions and ORBs are not that big.
The CD isn't the problem; memory is. And generally isn't that much
of a problem either.
>The people
>doing the kernel could set up the rules to implement things like CORBA
>Services and helper daemons (like interface repositories, or
>location/activation daemons) as modules. Having standard APIs or admin
>tools to do the basic management of each pieces (these could be just
>wrappers to whatever different admin interfaces of each ORB). The idea is,
>adding to the OS some smart standards, scripts and wrapper libs to make all
>ORBs look the same to the user, administrator, and as much as possible to
>the developer. This is almost as good as having a single standardized ORB.
The problem is that these aren't the levels at which one can expect
portability. There is portability at the IIOP level, and some
standardization of language bindings. But actually compiling components
is ORB-specific.
And it's not obvious that the "people doing the kernel" should
necessarily have anything to do with this. This stuff isn't part
of the kernel.
And further, the advantage is not in pretending that CORBA is in the
kernel, which immediately means that you've tied applications intimately
to Linux, but rather in abstracting that, so that applications don't
need to know about the kernel *at all.*
>...and its use by the OS to expose important features forces developers
>to learn it and write applications to it, and this helps to move the system
>to a more up-to-date reality.
I disagree. Strongly.
The history of Free Software shows that "making" developers do things
is rather like herding cats. You have to show to them that it is of
significant advantage *to them* to go in the direction you want them
to go. And even then, they won't actually follow you; they'll do
"their thing" that may start moving in your direction.
If you try to force people to change to a new API, that will be
regarded in much the same regard as Microsoft forcing the world from
Win16 to Win32. With the difference that you aren't the "dictator"
of what happens with free software, and you don't have billions of
dollars to deploy to use to convince people to do what you want them
to do.
In short, you *can't* force developers to write applications to your
"new reality." They are free to ignore you, and if you are strident
in your demands, they will be equally "strident" in their tendancy
to ignore you. The louder you get, the less success you'll have.
>I see that an OS like Linux has a big potential to become a _real_
>revolution. But this is not going to happen if developers insist on using
>technologies, APIs and standards from the seventies, no matter how open and
>how bug-free/efficient they are in Linux. This will only happen if you are
>bold enough to embrace today's and tomorrow's big opportunities (my best
>bets are CORBA and Java) and support them much better than other
>alternatives.
This only happens if you show people a "silver bullet" that makes it
unambiguously easier to deploy their applications.
That isn't so; what you *want* is afar off, and once you get there, it may
very well prove to be that it's not as effectual as you think.
After all, people are still writing software in C; C++, despite much
publicity and advocacy *and actual tools* doesn't weigh in as a terribly
commonly used tool in the applications in the average Linux distribution.
Adding a couple dozen KDE applications to a Linux distribution is likely
to double the number of programs written in C++. I did a count of
the apps in /usr/bin referencing C++ libs once and found a ludicrously
low percentage.
In order for there to be CORBA stuff, people have to be writing CORBA
oriented code. That's starting to be; it will literally take *years*
for there to be enough CORBA material to be more significant than the
"native C" stuff already out there. And you can't expect people to
jump over to CORBA when there's little code and little apparent benefit
to them.
In short, the transformation you'd like is absolutely not going to happen
instantly, nor will it happen as a "bold" complete transformation.
I'm a little skeptical that incremental evolutionary change can turn
hydrogen into people; what's clear is that with the community that exists,
we're going to see incremental evolutionary changes that do not step from
"Today, we use C, files, and UNIX API" to "Tomorrow, that is all replaced
by CORBA." Not going to happen.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: [EMAIL PROTECTED] (steve mcadams)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Sat, 16 Jan 1999 16:52:57 GMT
[Snipped for brevity, quoted material marked with ">"]
On Sat, 16 Jan 1999 03:06:34 GMT, [EMAIL PROTECTED] (Perry Pip)
wrote:
>On Fri, 15 Jan 1999 18:21:37 GMT, steve mcadams <[EMAIL PROTECTED]> wrote:
>>Generally C-language wrappers for C++ objects tend to be a bad idea;
>>on the other hand if you start with a C implementation then wrap it in
>>C++ you get the best of both worlds. (Unfortunately most people,
>>myself included, are probably too lazy to do this if they can just
>>write it in C++ to begin with.) -steve
>
>Well, fortunately, not everybody is so lazy. Check out www.gnome.org.
>Kudos to the Gnome team!!
I'll have to take a look at the GTK code sometime and see how it's
designed; I assume you're saying the GTK developers wrote a C version
and then added a C++ wrapper? I'm curious as to whether it's designed
for object orientation, or whether the C++ wrapper is a kludge; in my
experience those are the only two possibilities. Not that I have that
much experience with C++ wrappers, I've only seen a few (maybe a
dozen) in the past 5 years (since I started using C++). They were all
kludges, including (if not especially) MFC, which is a thin C++
wrapper over the C-language Windows API, which in turn is a kludge
because of its origins and upward compatability requirements. -steve
<offtopic>
You probably think I'm nuts because I'm writing a cross-system GUI
library and haven't looked at either Qt or GTK from the point of view
of someone who might use them; that's ok, the few people in WindowLand
that know what I'm doing probably think I'm nuts too. The bottom line
is that neither GTK or Qt can possibly be adequate for the purposes I
have in mind for my library; or that I really am nuts (don't ask which
my wife thinks is the case, I haven't told her about any of this
free-code business yet). <g>
</offtopic>
========================================================
Tools for programmers: http://www.codetools.com/showcase
------------------------------
** 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
******************************
