Linux-Development-Sys Digest #861, Volume #6 Tue, 22 Jun 99 16:14:10 EDT
Contents:
Re: Pro/ENGINEER FlexLM and LINUX (James Murray)
Re: WinModems and Linux (Lew Pitcher)
gcc byte packing of inherited class data (Bruce Edge)
Difficulty in compiling kernel 2.2.10 (Wei-shi Tsai)
Re: how to make tasks periodic ? (Medical Electronics Lab)
Re: gcc byte packing of inherited class data (Stefan Seefeld)
Re: gcc byte packing of inherited class data (Bruce Edge)
NT kernel guy playing with Linux (Holden McGroin)
Re: You can now use Winmodems in Linux!!!!!!! (Frank v Waveren)
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: WinModems and Linux (Medical Electronics Lab)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (James Murray)
Crossposted-To: comp.cad.pro-engineer,comp.os.linux.development.apps
Subject: Re: Pro/ENGINEER FlexLM and LINUX
Date: Mon, 21 Jun 1999 20:32:26 GMT
In article <7k6h53$p3i$[EMAIL PROTECTED]> Peter Samuelson
<[EMAIL PROTECTED]> writes:
>[<[EMAIL PROTECTED]>]
>> (note to PTC: Hurry up with Pro/E for LINUX!!!!!)
>
>Parametric is doing Pro/E for Linux? Hmmm, that would put Dassault in
I wish they'd port Cadds5, but then they hardly seem to be developing
it on their mainstream Unix platforms, just spending time on NT instead.
Would it not have been quicker to port to Linux and give away a
(maybe UMSDOS?) install CD?
I reported a serious CAM bug on the Solaris release a year ago and they seem
to have done sod all. (ncoutd daemon dies)
jsm
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Subject: Re: WinModems and Linux
Reply-To: [EMAIL PROTECTED]
Date: Tue, 22 Jun 1999 17:34:40 GMT
On Tue, 22 Jun 1999 11:17:18 -0400, "James Addison" <[EMAIL PROTECTED]> wrote:
>Not trying to flame anyone or any entity, but don't you think that Microsoft
>probably has deals signed and crap like that to prevent the provision of
>LinModem Drivers for WinModems?
>
>After all, creating a monopoly isn't about letting such controlling
>circumstances get out of control by letting manufacturers write drivers for
>every OS available.
>
>It's safe to ignore this post - honestly. :-)
I don't want to ignore your post; it brings up a couple of interesting thoughts.
First, I don't believe that Microsoft has a legal hold over *all* the manufacturers
of WinModems. However, they may have a legal hold on the largest manufacturers
(i.e. USR, etc.). Even in the Microsoft world, building a device driver isn't all
that difficult (albeit, more difficult than building a Linux device driver). The
technology to build one isn't licenced with approval from Microsoft (compilers, etc.).
However, it probably is *easier* to build a Microsoft device driver when you have
a legal agreement with Microsoft.
Second, even if *all* the current manufacturers of WinModems have exclusive licences
with Microsoft, there's no restriction on you, me, or the small electronics
manufacturer
down the street from going to Lucent or Rockwell and purchasing a HCF modem chipset and
the manuals and design notes. All it takes is money (sometimes small amounts). From
there,
there's no restriction on you, me, or that small manufacturer from building a modem out
of those parts, and writing drivers for that modem for whatever system he wishes.
Any hardware types want to *build* a Linux LinModem? Judging from the WinModem traffic
on the comp.os.linux.* newsgroups, you probably have a market.
Third (and last), what we are now talking about are three different issues:
a) the technical issue (can a Linux driver be written for our modem?),
b) the marketing issue (can we sell a modem that has a Linux driver?), and
c) the legal issue (are we legally permitted to sell a modem with a Linux driver?).
I believe that the technical issue is negligable ("Yes, we can write a Linux device
driver for our modem."), and the marketting issue is currently being re-evaluated
("Yes, it's becoming possible to sell a LinModem."). That leaves the legal issue
to be resolved. Any comments from USR/Jaton/Wisecom/anyone??
>--
>James Addison
>------------------------
>- "You know you're in sad shape when clouds remind you of zeros and ones."
>
>Lew Pitcher <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> I've suspected that (at least some) WinModems would be that simple.
>>
>> Here's a challenge then:
>>
>> Could someone with the specs for an existing WinModem (i.e. manufacturer
>> or licencee) write a two-part driver for your WinModem, and publish it
>> (either as LGPL modules or GPL source) for use?
>> - Part 1 would implement a state machine to translate Hayes AT commands
>> to WinModem module calls. This module would be generic so as to be
>able
>> to drive different WinModems, and would simply process the AT
>commandset
>> into something useable by the WinModem driver. Sorta like Ghostscript
>> does for the postscript language.
>> - Part 2 would implement a modem driver (data pump and modem control)
>for
>> your specific WinModem. The public API should be generic enough that
>> other manufacturers/authors could write similar drivers for alternate
>> WinModems. This driver would provide
>> a) read() and write() exits for data transfer to and from the modem,
>and
>> b) an ioctl() exit (or similar) for manipulation of the WinModem
>controls.
>> Publish the requirements of the driver API (which ioctls perform what
>functions),
>> and make the AT command interpreter free. You'll get *alot* of
>purchasers from
>> the non-windows community this way.
>>
>> On Tue, 22 Jun 1999 11:08:22 +0000, Craig Graham
><[EMAIL PROTECTED]>
>> wrote:
>>
>> >pzdev <[EMAIL PROTECTED]> wrote:
>> >> Please excuse me for not threading this with the main WinModems thread,
>> >> but I'm having problems with my newsreader.
>> >>=20
>> >> A few comments about using WinModems under Linux. Contrary to what has
>> >> been said in this forum, the reason that a WinModem is less expensive
>> >> and consumes more of the host CPU is not because it is using the host
>> >> CPU to perform the work of a UART in a normal modem. Rather, the
>> >> interface card in a typical WinModem is has very little hardware at
>all=
>> >:
>> >> typically a CODEC (D/A and A/D converter) and not much else. Most of
>> >> the modem functionality, including all the modulation, protocols, link
>> >> layers, and AT command processing happen on the host processor. In
>> >> essence, the driver for the WinModem *is* the modem, running on the
>hos=
>> >t
>> >> processor.
>> >
>> >Are you sure about that? I ask because I've programmed the Rockwell DP
>> >series chips direct before (we used the data pump chip directly in a
>sett=
>> >op
>> >box project I worked on a few years back). Admitedly they have no AT
>> >command set - all you have is a set of registers that you can access, but
>> >most of what you had to do was implement a state machine to control
>> >the data pump. The cost saving in a win-modem actually comes from not
>> >having a dedicated CPU and UART to translate AT commands from the
>> >serial port into direct register access sequences to control the data
>pum=
>> >p
>> >eg.=20
>> > ATDT 0181
>> >translates to=20
>> > 1) set the DTMF mode bit
>> > 2) set the output attenuation and DTMF twist to whatever the country's
>> > local telecoms spec is (it's different for each country, rockwell
>ch=
>> >ips
>> > default to US standards).
>> > 3) write each digit one at a time, waiting for a digit-done interupt
>bef=
>> >ore
>> > dialing the next one.
>> >You can then handle the connect/negotiation sequence via a simple
>> >set a bit/poll the next phase bit sequence. Once the connection is made,
>> >you have one register for data out, one for data in, an interupt line for
>> >transmit/recieve and a status register. Simple.
>> >There isn't really any DSP done on the Host CPU, and it's not that much
>> >harder than an AT type modem to write a driver for - in fact, you should
>> >be able to do a much better linux driver for it than for an AT type modem
>> >(what everyone here considers a 'real' one).
>> >
>> >
>> >> pzdev
>> >
>> >Craig Graham.
>> >
>>
>>
>> Lew Pitcher
>> System Consultant, Integration Solutions Architecture
>> Toronto Dominion Bank
>>
>> ([EMAIL PROTECTED])
>>
>>
>> (Opinions expressed are my own, not my employer's.)
>
>
Lew Pitcher
System Consultant, Integration Solutions Architecture
Toronto Dominion Bank
([EMAIL PROTECTED])
(Opinions expressed are my own, not my employer's.)
------------------------------
From: Bruce Edge <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc,gnu.g++,comp.os.linux.development
Subject: gcc byte packing of inherited class data
Date: Tue, 22 Jun 1999 18:27:42 +0000
I can't get gcc to pack this data:
class a
{
char c;
};
class b
{
long l;
};
class c : public a, public b
{
};
Without going into why I need a misaligned long after a char,
I need the alignment for class c to be:
cc ll ll ll ll
not:
cc xx xx xx ll ll ll ll
which it insists on doing regardless of which attribute/packed
parameters I use.
TIA, Bruce.
--
Bruce Edge bedge@sat/_noXXXspam_/tel.com
Sattel Global Networks 818.709.6201 x122
------------------------------
From: Wei-shi Tsai <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Difficulty in compiling kernel 2.2.10
Date: Tue, 22 Jun 1999 16:32:26 GMT
I recently downloaded the source to the 2.2.10 kernel. I configured
using make menuconfig to my satisfaction.
However, when I compiled the kernel using "make zlilo", it goes almost
perfectly (a few warnings) but suddenly while the assembler portion of
the kernel is being compiled, the whole compilation stops with an error
message.
I tried again with "make zImage", but the compilation stops at the exact
same point. What is going on????
--
Wei-shi Tsai
Cymbeline on #descent, Kahn, and ICQ(UIN:2801023)
The Lost Material Defender Page:
http://www.crosswinds.net/dallas/~perdita/index.html
MoonieCode(1.8.11):
SM:5+ F:sMe++>Mo+>:vZo<Bl+>:aLu+Ry+:pClR2 D:sMa<:vBe-Wi-> X:a0s|35d++
O:d+:s?:?o?:a--:h--- P:a+:s6:w-:f?:eBrD:hBkm:t-:cAs:y---:r+|
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: how to make tasks periodic ?
Date: Tue, 22 Jun 1999 13:10:22 -0500
Johan Kullstam wrote:
> if you need to support deadline scheduling, get a different operating
> system. i think there's some kind of real-time linux where a small
> real-time kernel runs linux as a subprocess.
There is definitly a real-time linux:
http://www.rtlinux.org/~rtlinux/
Patience, persistence, truth,
Dr. mike
------------------------------
From: Stefan Seefeld <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc,gnu.g++,comp.os.linux.development
Subject: Re: gcc byte packing of inherited class data
Date: Tue, 22 Jun 1999 18:50:09 GMT
Bruce Edge wrote:
>
> I can't get gcc to pack this data:
>
> class a
> {
> char c;
> };
>
> class b
> {
> long l;
> };
>
> class c : public a, public b
> {
>
> };
>
> Without going into why I need a misaligned long after a char,
> I need the alignment for class c to be:
>
> cc ll ll ll ll
>
> not:
>
> cc xx xx xx ll ll ll ll
given your requested alignment, how would you expect a cast from
(c *) to (b *) to work ? It doesn't give a valid address.
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
------------------------------
From: Bruce Edge <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc,gnu.g++,comp.os.linux.development
Subject: Re: gcc byte packing of inherited class data
Date: Tue, 22 Jun 1999 18:57:40 +0000
Stefan Seefeld wrote:
>
> Bruce Edge wrote:
> >
> > I can't get gcc to pack this data:
> >
> > class a
> > {
> > char c;
> > };
> >
> > class b
> > {
> > long l;
> > };
> >
> > class c : public a, public b
> > {
> >
> > };
> >
> > Without going into why I need a misaligned long after a char,
> > I need the alignment for class c to be:
> >
> > cc ll ll ll ll
> >
> > not:
> >
> > cc xx xx xx ll ll ll ll
>
> given your requested alignment, how would you expect a cast from
> (c *) to (b *) to work ? It doesn't give a valid address.
I admit to being new to linux programming, but I'm not sure what you
mean by a valid address, are you referring to having a long on a
misaligned
boundry?
This works on QNX.
-Bruce.
------------------------------
From: [EMAIL PROTECTED] (Holden McGroin)
Subject: NT kernel guy playing with Linux
Date: Tue, 22 Jun 1999 17:09:45 GMT
Its fun to get into a new OS. Never mucked with Linux before. I've
been doing NT kernel stuff for a few years.
Any uplifting comments for someone new to the linux faith would be
helpful...
Read Rubini's linux dvice driver book (which seems to cover up to
2.1.43 of linux). I must say, I'm a little disappointed in the linux's
apparent non-reentrancy. Rubini says there's a global semaphore that
is grabbed every time a process enters the kernel.
Additionally, linux's SMP handling doesn't seem to be very robust.
Processes can run on multiple processORS in user mode just fine. But,
enter the kernel and your SMP is HOZED.
Only one processor (BP) can handle interrupts in SMP too. So if a
process is in the kernel in another processor, interrupts are not
handled?
Also, Rubini doesn't say much about threads in the kernel. Maybe
they're in 2.2.xx ??
He mentions PThread's, but says these are manufactured threads in the
process and the kernel still sees one process. Therefore if a pthread
does something in the kernel, the other threads in the process don't
run.
Don't take this as a flame against Linux or anything. I honestly am
eager to continue delving into Linux at least as a hobby, and will
live in whatever environment that entails.
The things I like about NT are:
1) the IRP model. That is, each request from user mode is handed to
the kernel as an IRP (IO Request Packet). ALL drivers receive IRPs.
Any driver can generate a new IRP for a lower driver, or pass a
received IRP onto a lower driver. Therefore a driver doesn't know or
care whether a user mode app is talking it or another driver. IRPs
have a stack mechanism to allow a single IRP (with associated user
mode buffer etc) to pass through multiple layers of drivers. Any 3rd
party driver can install itself as a "filter" on top of any other
driver. As a filter, this driver gets first and last crack at all IRPs
coming and going to the original driver. Good for multimedia or just
plain hacking. IRP processing is completely asynchronous. Ie, when a
driver receives and IRP, it is free to process it as it wishs
(immediately or later). When the driver is finished processing the
IRP, it "completes" it; it tells NT via CompleteIrp(). So, when an app
thread does something that sends an IRP to kernel mode (like read a
file), the thread can either wait for the read to finish, or it can
merily go on doing other stuff while the read completes async,
signalling an event (semaphore). This "overlapping" is good for double
buffering reads and writes to a driver. A dedicated read thread can
send down multiple readfile's, and wait for their respective events to
be signalled. Therefore, if done right, no memory copying is necessary
from the hardware event all the way up to the application, even
through multiple driver layers. Same for writes. Also, since drivers
talk to other drivers by sending their own IRPs, driver A can ask
driver B to do something. Driver B sees an IRP. It doesn't know or
care if it is coming from user mode or another driver. It simply
processes it and completes it when it wants (sync or async). Driver A
gets notified when the IRP is completed by driver B. Driver A is free
to set up a kernel thread and semaphore to wait for the IRP
completion. Or it can overlap (double buffer) requests to driver B
however it wants.
2) all hardware interrupts have the same priority. This presumably is
a better model for spreading interrupt handling across SMP. There are
special high priority queues (one for each processor) built into NT
that drivers can use to process interrupts and IRPs. So all of this
happens across SMP.
3) completely reentrant and preemptible. Subject to priorities.
Meaning a driver can raise itself to a high enough priority to stop
just about anything in the system. But this is under driver control.
The system doesn't simply lock while the driver is doing something
unless the driver explicitly wants it to. For example, at "passive
level" (application level) there are priorities 0 through 31. 16 and
up is "realtime" class. 0 is idle (you're preempted if the user so
much as sneezes). Drivers can run at any of these. ie; the mouse
appears to be at around 25. Then there is "dispatch level" which is
above these 0-31 app priorities. Many drivers pass their IRPs through
a global dispatch queue (one for each processor) which runs at this
level. Above that is interrupt level.
I think it would be fun to do an NT kernel IRP emulation environment
in Linux that would allow some NT kernel drivers to run in binary
form, and most to port with very little changes.
Any comments of encouragment from the Linux world world be great.
Thanks
------------------------------
From: [EMAIL PROTECTED] (Frank v Waveren)
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: Tue, 22 Jun 1999 20:30:59 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> writes:
> The winmodem is just a digitizer that does DMA into a buffer. The
> processor has to convert the audio bits to multiple tone data, and
> then to data bits. It's straight forward data manipulation. There
> is no reason we can't write a driver for any winmodem.
1) The hardware interface of the winmodems is undocumented, and from what I heard
not very simple
2) Programming all of the modem protocol is going to be a lot of work, especially
if you want to use the standards.. (Why else have a modem?)
If anyone want to, let them feel free to, but I think that it would be better
to convince the vendors....
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Tue, 22 Jun 1999 19:49:02 GMT
Christopher B. Browne ([EMAIL PROTECTED]) wrote:
: The advantage to the "lack" of forced support is that it doesn't force
: people into a particular approach by making it permeate the kernel.
: Supposing there was, in the Linux kernel, a record-oriented DB scheme not
: unlike the (boo, hiss!) "Windows Registry," people would be encouraged to
: push things into The Database that don't fit properly.
I don't understand the implied comparison of the registry to SQL or other
databases.. it seems to me they are fundamentally designed to accomplish
different means.. the registry is just "program data/parameters"..
databases are general purpose /high performance
data holders/indexers/sorters/retrievers etc.
also: I don't like the windows registry implementation either (have
had my share of its incredibly awkward interface), but I think
the overall idea of the OS imposing a sort of ordering on the way that
apps store their data is appropriate...
question for you: would there be a way to implement the registry in
a more streamlined way in which you wouldnt "boo hiss" it.. also for what
reasons are you "boo hissing" it?
: The situation with Linux is rather more like "herding cats." You're not
: going to force people to use "libDataBase," although if it happens to be
: good enough, the cats *will* circle it as they would food. You can't
: *force* use; you can only *persuade,* and must persuade via having provided
: a result that satisfies the "cats'" hopes and expectations.
that's true & one of the great aspects of linux which I
heartily support.. but there are other elements of the OS that are built
in that everyone uses. perhaps the reason that
extremely complex features are not built
into the OS is not because they are not desired, or that they
degrade performance, but that there is a lack of consensus on how
they should be incorporated..
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: WinModems and Linux
Date: Tue, 22 Jun 1999 14:09:52 -0500
Lew Pitcher wrote:
>
> I've suspected that (at least some) WinModems would be that simple.
>
> Here's a challenge then:
>
> Could someone with the specs for an existing WinModem (i.e. manufacturer
> or licencee) write a two-part driver for your WinModem, and publish it
> (either as LGPL modules or GPL source) for use?
I just put in a call to the FAE at PCTel. Maybe I can get some data
sheets on either the 1789 or 789 chips in my Winmodem.
> - Part 1 would implement a state machine to translate Hayes AT commands
> to WinModem module calls. This module would be generic so as to be able
> to drive different WinModems, and would simply process the AT commandset
> into something useable by the WinModem driver. Sorta like Ghostscript
> does for the postscript language.
That's high level stuff, I'd make it part 2, i.e. do it second.
> - Part 2 would implement a modem driver (data pump and modem control) for
> your specific WinModem. The public API should be generic enough that
> other manufacturers/authors could write similar drivers for alternate
> WinModems. This driver would provide
> a) read() and write() exits for data transfer to and from the modem, and
> b) an ioctl() exit (or similar) for manipulation of the WinModem controls.
> Publish the requirements of the driver API (which ioctls perform what functions),
> and make the AT command interpreter free. You'll get *alot* of purchasers from
> the non-windows community this way.
I'd be a bit more expansive, but that's the basic way to go.
Let's see what PCTel says. If an extra sales of 1000/month doesn't
turn them on, I'll have to reverse engineer the thing. That's
a major pain, but it's also just the challenge of it. If it's
reverse engineered, we can certainly give all the code away for
free. If we get data sheets under ND, then at least the API can
be published and the binaries given away.
In any case, there are several different "winmodem" designs.
The PCTel is called HSP or Host Support Protocol, meaning the
DSP work is done by the host processor. This steals processing
power from the host, so it's not very useful if you're trying
to do heavy duty processing at the same time you're logged in
to the net. For me, it's plenty useful.
Anybody else up for the challenge?
Patience, persistence, truth,
Dr. mike
------------------------------
** 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
******************************
