[9fans] const

[9fans] const

[Steve Simon]

I'm trying to find a reference to a tirade against
the C const type qualifier. I think it was writtent
during the ANSI-isation of C by dmr or perhaps bwk,
(or was it was rob).

Anyone got a link to this or did I imagine it?

-Steve

Re: [9fans] const

[Russ Cox]

> I'm trying to find a reference to a tirade against
> the C const type qualifier. I think it was writtent
> during the ANSI-isation of C by dmr or perhaps bwk,
> (or was it was rob).

http://www.lysator.liu.se/c/dmr-on-noalias.html
http://tinyurl.com/8435y

The second (actually a Google Groups url) explains the first.

Russ

Re: [9fans] const

[erik quanstrom]

i've found const pretty useful, dispite the fact it does create some inconsistencies.
it's chief virtue is that you can tell without looking any further than the prototype
that a function that takes a const char* makes it's own copy, if it needs one. 

if you're careful with const, i think it can be a help in preventing some silly mistakes
that will cause a benign looking program to get up and fandango on core.

unfortunately, glibc, for example, is not very consistant. dispite the fact that it returns
a pointer into envp, glibc getenv is declared as "char* getenv(const char*);". 

- erik

Russ Cox <rsc@swtch.com> writes

| 
| > I'm trying to find a reference to a tirade against
| > the C const type qualifier. I think it was writtent
| > during the ANSI-isation of C by dmr or perhaps bwk,
| > (or was it was rob).
| 
| http://www.lysator.liu.se/c/dmr-on-noalias.html
| http://tinyurl.com/8435y
| 
| The second (actually a Google Groups url) explains the first.
| 
| Russ

Re: [9fans] const

["Nils O. Selåsdal"]

erik quanstrom wrote:
> i've found const pretty useful, dispite the fact it does create some inconsistencies.
> it's chief virtue is that you can tell without looking any further than the prototype
> that a function that takes a const char* makes it's own copy, if it needs one. 
> 
> if you're careful with const, i think it can be a help in preventing some silly mistakes
> that will cause a benign looking program to get up and fandango on core.
Helps various unixes with (micro?)optimizations as well, which places 
const data in
read only sections which then are normally shared between multiple
instances.

> unfortunately, glibc, for example, is not very consistant. dispite the fact that it returns
> a pointer into envp, glibc getenv is declared as "char* getenv(const char*);". 

That's exactly how ISO C(99) and posix[1] declares it, I suppose  you
could blame them. (envp is modifiable on my BSD atleast though. C99
marks it as undefined behavior if you modify it)


[1] http://www.opengroup.org/onlinepubs/009695399/functions/getenv.html

Re: [9fans] const

[Steve Simon]

My understanding is that const was depricated for the same reason that
register is - the compiler is in a much better position to judge what
data is constant than the programmer.

The one place where it would have been very useful (to me) was
writing ROMable embedded code, but these days with 32bit embedded
CPUs I don't have physicially readonly data.

To cap this the last time I did use a 16bit cpu and tried to do this,
examination of the assembly proved the (name deleted) compiler was too
dumb to take advantage.

-Steve

Re: [9fans] const

[Lucio De Re]

> To cap this the last time I did use a 16bit cpu and tried to do this,
> examination of the assembly proved the (name deleted) compiler was too
> dumb to take advantage.

Now, irrespective of which compiler Steve is referring to...

In the delusion that I may have to migrate to embedded systems when my
luck with system and network administration runs out, I follow the
traffic on the avr-gcc mailing list.  Even though criticism on _this_
list of GCC is often borne out there, one has to grant that avr-gcc is
a dramatically superior product to any other offering for the target
CPU.

GCC is a monstrosity, but nothing else addresses all the issues that
it resolves.  The cost is extremely high, but in my opinion it is
worth paying.  I think GCC is closer to an organism than to a formal
translator and that may well be its strongest suit.

++L

Re: [9fans] const

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

>>list of GCC is often borne out there, one has to grant that avr-gcc is
>>a dramatically superior product to any other offering for the target
>>CPU.

that's funny.  before i read it, i was just about to observe that our Atmel compiler
based on Plan 9's puts tables in program flash without any hints.
const alone wouldn't help anyway because the memory is accessed
using special instructions so the compiler and linker need to do
more analysis.  otherwise the compiler does reasonable well given
that the chip is really an 8-bit micro.  i think
the loader zl helps zc in some cases, and also monitors stack sizes.
it was important that the FFT and CC1000
tables go in program memory to save limited RAM,
although that feature was added fairly late.
we needed the atmel compiler for some work on motes.
i looked at gcc for it a bit initially whilst waiting for ours
but started to throw things or throw up; i can't remember which.

[-- Attachment #2: Type: message/rfc822, Size: 3105 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] const
Date: Wed, 7 Dec 2005 17:30:42 +0200
Message-ID: <16513104bf876d67dcbb094b8f545d54@proxima.alt.za>

> To cap this the last time I did use a 16bit cpu and tried to do this,
> examination of the assembly proved the (name deleted) compiler was too
> dumb to take advantage.

Now, irrespective of which compiler Steve is referring to...

In the delusion that I may have to migrate to embedded systems when my
luck with system and network administration runs out, I follow the
traffic on the avr-gcc mailing list.  Even though criticism on _this_
list of GCC is often borne out there, one has to grant that avr-gcc is
a dramatically superior product to any other offering for the target
CPU.

GCC is a monstrosity, but nothing else addresses all the issues that
it resolves.  The cost is extremely high, but in my opinion it is
worth paying.  I think GCC is closer to an organism than to a formal
translator and that may well be its strongest suit.

++L

Re: [9fans] const

["Nils O. Selåsdal"]

Paul Lalonde wrote:
> Here's a related question: There are read-only (const) variables, and 
> read-write variables.  Is there any way to notate a write-only variable 
> in C?  I'd like to be able to denote that something is a stream 

/* Don't read from this */
Should suffice.

Re: [9fans] const

[Paul Lalonde]

If only!  Most of my life has been writing libraries for game  
programmers to use.  If you think Linux is a strange and scary place,  
you ain't seen nothing yet.  If the compiler can't enforce the  
convention, you can't rely on it.

Paul

On 7-Dec-05, at 8:11 AM, Nils O. Selåsdal wrote:

> Paul Lalonde wrote:
>> Here's a related question: There are read-only (const) variables,  
>> and read-write variables.  Is there any way to notate a write-only  
>> variable in C?  I'd like to be able to denote that something is a  
>> stream
>
> /* Don't read from this */
> Should suffice.
>
>
>

Re: [9fans] const

[jmk]

/sys/games/lib/fortunes:2176: I'd rather have :rofix than const.  -DM Ritchie

Re: [9fans] const

[Skip Tavakkolian]

> /sys/games/lib/fortunes:2176: I'd rather have :rofix than const.  -DM Ritchie

nice!

Re: [9fans] const

[Joel Salomon]

On 12/7/05, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote:
> /sys/games/lib/fortunes:2176: I'd rather have :rofix than const.  -DM Ritchie

:rofix ?

Re: [9fans] const

[Charles Forsyth]

>:rofix ?

(on unix) cc -S something.c
	./:rofix something.s
	as -o something.o something.s

where :rofix is a sh/ed/sed script that changes certain .data to .text

Re: [9fans] const

[Joel Salomon]

On 12/7/05, Charles Forsyth <forsyth@terzarima.net> wrote:
> (on unix) cc -S something.c
>         ./:rofix something.s
>         as -o something.o something.s
>
> where :rofix is a sh/ed/sed script that changes certain .data to .text

So it does the optimization possible with const.  Not the "interface"
part, though.  If you don't like type decorations, I guess this way's
better.

--Joel

Re: [9fans] const

[Brantley Coile]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

It was a way to move the string from the data segment to the text segment.
I never found it useful and making strings const char * broke lots
of programs that wrote directly into strings.  No big deal, but a useless pain.
I tire of paying for things I don't use. :(

 1011 1100 

[-- Attachment #2: Type: message/rfc822, Size: 3493 bytes --]

From: Joel Salomon <joelcsalomon@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] const
Date: Wed, 7 Dec 2005 14:30:17 -0500
Message-ID: <7871fcf50512071130m475c7240i3c65da1b4c900c15@mail.gmail.com>

On 12/7/05, Charles Forsyth <forsyth@terzarima.net> wrote:
> (on unix) cc -S something.c
>         ./:rofix something.s
>         as -o something.o something.s
>
> where :rofix is a sh/ed/sed script that changes certain .data to .text

So it does the optimization possible with const.  Not the "interface"
part, though.  If you don't like type decorations, I guess this way's
better.

--Joel

Re: [9fans] const

[rog]

> So it does the optimization possible with const.  Not the "interface"
> part, though.  If you don't like type decorations, I guess this way's
> better.

from my point of view, const pretends to be something it isn't.
it does not guarantee you anything at all (it is routinely necessary
to cast from const to non-const), and most ironically of all,
in the only place where const would actually mean something,
literal strings, which are often held in read-only memory,
the type is not const qualified.

Re: [9fans] const

[Charles Forsyth]

> So it does the optimization possible with const.  Not the "interface"
> part, though.  If you don't like type decorations, I guess this way's
> better.

it's not so much type decorations, as those that are not terribly useful or to some extent misleading.
(mind you, java programs look like christmas trees--holiday trees to those of you in the US--
with all their type and status decorations.)

if you followed the earlier links you'll see one of the classic examples
of it being fairly odd as an interface constraint:

	char* strchr(const char* x, int y)

but the resulting pointer points into the const string and ok, it doesn't write to it itself, but it
hands you back a pointer into the same string so you can do it yourself!
that's wierd, especially since it must effectively have cast x to plain char* internally
so it's not much of a constraint either way.

i find it's really a device for forcing the adding and removing of const
until a compiler shuts up.   this is unusual, because most type clash diagnostics do mean something;
perhaps not all that much, but something.   perhaps i'm lucky, but i have found bugs through
type clashes (often when checking extern linkages) but i can't remember a single thing detected by const.
it's one of those things where ``now it's there we might as well try to use it'' but i'm afraid i'm unconvinced.

Re: [9fans] const

[Bruce Ellis]

ken had total disregard for const and that is good enough for me.

i rememeber :rofix and other such hacks, but that was when memory
was an issue.

brucee

On 12/8/05, Charles Forsyth <forsyth@terzarima.net> wrote:
> > So it does the optimization possible with const.  Not the "interface"
> > part, though.  If you don't like type decorations, I guess this way's
> > better.
>
> it's not so much type decorations, as those that are not terribly useful or to some extent misleading.
> (mind you, java programs look like christmas trees--holiday trees to those of you in the US--
> with all their type and status decorations.)
>
> if you followed the earlier links you'll see one of the classic examples
> of it being fairly odd as an interface constraint:
>
>        char* strchr(const char* x, int y)
>
> but the resulting pointer points into the const string and ok, it doesn't write to it itself, but it
> hands you back a pointer into the same string so you can do it yourself!
> that's wierd, especially since it must effectively have cast x to plain char* internally
> so it's not much of a constraint either way.
>
> i find it's really a device for forcing the adding and removing of const
> until a compiler shuts up.   this is unusual, because most type clash diagnostics do mean something;
> perhaps not all that much, but something.   perhaps i'm lucky, but i have found bugs through
> type clashes (often when checking extern linkages) but i can't remember a single thing detected by const.
> it's one of those things where ``now it's there we might as well try to use it'' but i'm afraid i'm unconvinced.
>
>

Re: [9fans] const

[Paul Lalonde]

On 7-Dec-05, at 1:07 PM, Charles Forsyth wrote:
> if you followed the earlier links you'll see one of the classic  
> examples
> of it being fairly odd as an interface constraint:
>
> 	char* strchr(const char* x, int y)

I call this an interface bug: really, it should return a const char  
*, not a char *.  For the case where the input string was not const  
the user can obviously strip the constness from the return value.

It is a clear example of trying to make a piece of notation do two  
things.  One is to say that the function does not modify its  
paramter, which is of clear benefit to the optimizer when calling the  
function.  The second is to say that the data pointed to should not  
be changed, which is a semantic constraint for the programmer.
Ugly.

Paul

Re: [9fans] const

[Rob Pike]

It's the property of strchr that's truly const, not its arguments.
Expressing this in the arguments leads to this sort of silliness.

I've always thought constancy should be a property of
where something is stored, not its type.  (Hence :rofix
for instance.)

Reiterating what someone said, 'const' is too simple a notion
to encode optimization opportunities and too invasive a notion
to sit well in any practical code.

-rob

On 12/7/05, Paul Lalonde <plalonde@telus.net> wrote:
>
> On 7-Dec-05, at 1:07 PM, Charles Forsyth wrote:
> > if you followed the earlier links you'll see one of the classic
> > examples
> > of it being fairly odd as an interface constraint:
> >
> >       char* strchr(const char* x, int y)
>
> I call this an interface bug: really, it should return a const char
> *, not a char *.  For the case where the input string was not const
> the user can obviously strip the constness from the return value.
>
> It is a clear example of trying to make a piece of notation do two
> things.  One is to say that the function does not modify its
> paramter, which is of clear benefit to the optimizer when calling the
> function.  The second is to say that the data pointed to should not
> be changed, which is a semantic constraint for the programmer.
> Ugly.
>
> Paul
>
>
>

Re: [9fans] const

[Micah Stetson]

> (mind you, java programs look like christmas trees--holiday trees to those of you in the US--

I think Channukwanzaamastice is the best name for the collective of
politically correct celebrations that may or may not occur in your
home at this time of year.  It contains part of the name of each of
the major celebrations, symbolizing both our diversity and solidarity.
 It does not mention Christ, because he wasn't open-minded enough to
accept that each person's diverse beliefs are equally valid, however
contradictory.  And it sounds like a disease, which is not
innaccurate.

Micah

Re: [9fans] const

[Micah Stetson]

> I think Channukwanzaamastice is the best name for the collective of

Oops, I didn't mean to send that to the list.  Sorry for the sarcastic noise.

Micah

Re: [9fans] const

[Brantley Coile]

[-- Attachment #1: Type: text/plain, Size: 80 bytes --]

No problem.  Merry Chirstmas everybody!

Brantley
	(in the US and Baptist.)

[-- Attachment #2: Type: message/rfc822, Size: 3218 bytes --]

From: Micah Stetson <micah@stetsonnet.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] const
Date: Wed, 7 Dec 2005 14:44:59 -0800
Message-ID: <b3b4f6f30512071444k11628698i390861695427ab53@mail.gmail.com>

> I think Channukwanzaamastice is the best name for the collective of

Oops, I didn't mean to send that to the list.  Sorry for the sarcastic noise.

Micah

Re: [9fans] const

[Skip Tavakkolian]

>> /sys/games/lib/fortunes:2176: I'd rather have :rofix than const.  -DM Ritchie
> 
> :rofix ?

http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/vi/port/rofix

Re: [9fans] const

[geoff]

I like Ken's comment in A New C Compiler:

Volatile seems to have no meaning, so it is hard to tell if ignoring
it is a departure from the standard.  Const only confuses library
interfaces with the hope of catching some rare errors.

Re: [9fans] const

[Lucio De Re]

> I like Ken's comment in A New C Compiler:

This is a document I've long missed, where is it?

++L

Re: [9fans] const

[geoff]

`A New C Compiler' was in the Summer 1990 UKUUG proceedings, but
Google finds it also at

http://www.ibiblio.org/pub/academic/computer-science/operating-systems/plan9/8-c-compiler.ps.Z

Re: [9fans] const

[Bruce Ellis]

indeed - it was a long time ago (gnot days).

brucee

On 12/8/05, geoff@collyer.net <geoff@collyer.net> wrote:
> `A New C Compiler' was in the Summer 1990 UKUUG proceedings, but
> Google finds it also at
>
> http://www.ibiblio.org/pub/academic/computer-science/operating-systems/plan9/8-c-compiler.ps.Z

Re: [9fans] const

[Brantley Coile]

> I like Ken's comment in A New C Compiler:
> 
> Volatile seems to have no meaning, so it is hard to tell if ignoring
> it is a departure from the standard.  Const only confuses library
> interfaces with the hope of catching some rare errors.

Indeed.  But does the keyword do anything in the current compilers?
It doesn't seem like the keyword gets ignored. Several [.]VOLATILE
constants and a command in 8c/sgen.c:370.

 bc
 

Re: [9fans] const

[geoff]

At a quick read, it appears that `const' and `volatile' are treated as
`garbage type qualifiers' and ignored.

Re: [9fans] const

[Russ Cox]

> At a quick read, it appears that `const' and `volatile' are treated as
> `garbage type qualifiers' and ignored.

Const is ignored.  Volatile is not ignored anymore.
/sys/src/cmd/cc/dcl.c:768 or so inserts USED(&x)
if you declare volatile int x;, presumably so that
the compiler will not registerize x.  This is occasionally
necessary in the kernel because of waserror().
For example:

    x = 0;
    if(waserror()){
        print("x=%d\n", x);
        nexterror();
    }
    x = 1;
    x = f(x);

If f errors, then the waserror might print 0 if the compiler
has chosen not to store the 1 (it's not used after the call
to f -- it will be overwritten once f returns).

This happens in namec in /sys/src/9/port/chan.c.  Rob defined
an empty function saveregisters() and called it to force the
compiler to write the new value of x to memory before calling f
(in this case, devtab[c->type]->open).  It could be replaced
by making c volatile now, though I'd rather not.

Russ

Re: [9fans] const

[geoff]

On closer inspection, `const' isn't completely ignored either.  It can
generate warnings at /sys/src/cmd/cc/sub.c:510 and :524.

Re: [9fans] const

[Charles Forsyth]

> the compiler will not registerize x.  This is occasionally
> necessary in the kernel because of waserror().
> For example:
> 
>     x = 0;
>     if(waserror()){
>         print("x=%d\n", x);
>         nexterror();
>     }
>     x = 1;
>     x = f(x);

i think i'ts usually better to (re)write these to avoid confusing the compiler,
for instance by doing a new waserror/nexterror following x=1,
although if x changes value frequently, that's difficult.

Re: [9fans] const

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On 12/7/05, geoff@collyer.net <geoff@collyer.net> wrote:
>
> I like Ken's comment in A New C Compiler:
>
> Volatile seems to have no meaning, so it is hard to tell if ignoring
> it is a departure from the standard.  Const only confuses library
> interfaces with the hope of catching some rare errors.



Volatile is useful for telling compilers not to stick  data in registers,
which is helpful for multi-threaded situations with shared memory ...
sometimes :)

If I were to write a semaphore or another synchronization method using
shared memory on unix I'd probably type volatile and then pray :).

It often feels more of a faith issue than a knowledge issue though :)

Const is ok, sometimes, in some languages [C++].  It's notoriously difficult
to add const interfaacs to C++ classes as an afterthought.  You have to go
in "full const" or none at all.  Adding it afterwards causes a great deal of
pain tracking down all the places you needed const when you didn't put it
there.

It's like playing pick up sticks with your buttcheeks. - [I think] the late
John Candy.

[-- Attachment #2: Type: text/html, Size: 1496 bytes --]

Re: [9fans] const

[Richard Bilson]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On 12/9/05, David Leimbach <leimy2k@gmail.com> wrote:
>
> Volatile is useful for telling compilers not to stick  data in registers,
> which is helpful for multi-threaded situations with shared memory ...
> sometimes :)
>
> If I were to write a semaphore or another synchronization method using
> shared memory on unix I'd probably type volatile and then pray :).
>
> It often feels more of a faith issue than a knowledge issue though :)
>

It is a matter of faith, and usually misplaced at that, since volatile isn't
usually defined to place any constraints on the order in which operations
become visible to other processors. Certainly not in the C, C++, or POSIX
standards, although some platform ABIs do specify this to some degree.

Both POSIX and C++ are trying to deal with this, but it's an uphill battle
since processors differ widely on the sorts of constraints that they can
support efficiently.

In the meantime, people sprinkle volatile around and pray. All the world's
an x86, right?

[-- Attachment #2: Type: text/html, Size: 1334 bytes --]

Re: [9fans] const

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

> It is a matter of faith, and usually misplaced at that, since volatile
> isn't usually defined to place any constraints on the order in which
> operations become visible to other processors. Certainly not in the C, C++,
> or POSIX standards, although some platform ABIs do specify this to some
> degree.
>
> Both POSIX and C++ are trying to deal with this, but it's an uphill battle
> since processors differ widely on the sorts of constraints that they can
> support efficiently.
>
> In the meantime, people sprinkle volatile around and pray. All the world's
> an x86, right?
>

I think I'd be happier with new compiler pragmas in this case than a
keyword.  Then at least I KNOW that it can be ignored and will be optionally
supported by compilers on a per-case basis.

But then again, that's also true for "inline" in C++.  It's just a
suggestion, one that can be ignored.  The compiler can also inline stuff I
didn't ask it to.  [C99  has inline now too doesn't it?]

[-- Attachment #2: Type: text/html, Size: 1230 bytes --]

Re: [9fans] const

[Richard Bilson]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

On 12/9/05, David Leimbach <leimy2k@gmail.com> wrote:
>
>
> I think I'd be happier with new compiler pragmas in this case than a
> keyword.  Then at least I KNOW that it can be ignored and will be optionally
> supported by compilers on a per-case basis.
>
> But then again, that's also true for "inline" in C++.  It's just a
> suggestion, one that can be ignored.  The compiler can also inline stuff I
> didn't ask it to.  [C99  has inline now too doesn't it?]


The difference is that with memory barriers it's often the case that the
correctness of the algorithm depends on the placement of the barriers.
Consider writing a portable spin-lock: it's crucial that other processors
not be able to observe the lock open unless they also observe previous
memory writes in the critical section. But, in the absence of memory
barriers, many CPUs don't guarantee this.

The simple answer, of course, is to put the barriers in non-portable lock
code and use the locks to protect shared state. But the general experience
seems to be that programmers will try anything to avoid locks, for
performance reasons. Double-checked locking is the classic example -- it's
such a popular idiom that Java redefined the meaning of "volatile" to make
it work. C++ will probably do something similar.

And yes, C99 has inline, but to make things interesting they gave it a
slightly different meaning than in C++.

[-- Attachment #2: Type: text/html, Size: 1772 bytes --]

Re: [9fans] const

[Ronald G Minnich]

David Leimbach wrote:

> Volatile is useful for telling compilers not to stick  data in 
> registers, which is helpful for multi-threaded situations with shared 
> memory ... sometimes :)

and, stuff that tickles hardware. Refer to the old crazy stuff bsd did 
in the early 80s to get around those issues and still optimize drivers. 
Now, wonder if that script could even be found at this point.

I think I missed the part of the discussion that explains how to do 
mmap'ed I/O without volatile, and a good idea of how to tweak the 
compiler, such that:

while (x->statux & BUSY)
	;

works. If the answer is "don't optimize that functions, you idiot!" I'm 
actually ok with that.

ron

Re: [9fans] const

[Russ Cox]

> and, stuff that tickles hardware. Refer to the old crazy stuff bsd did
> in the early 80s to get around those issues and still optimize drivers.
> Now, wonder if that script could even be found at this point.
>
> I think I missed the part of the discussion that explains how to do
> mmap'ed I/O without volatile, and a good idea of how to tweak the
> compiler, such that:
>
> while (x->statux & BUSY)
>         ;
>
> works. If the answer is "don't optimize that functions, you idiot!" I'm
> actually ok with that.

On Plan 9, the compiler does not cache the results of
explicit memory reads like x->status.  So this is not a problem.

Russ

[9fans] PCICIA Modem

[TamTam]

Hi all!

I have Plan 9 on an very old Vaio 266 Mhz Notebook without any ethernet. 
Fortunately I have a PCICIA Modem, but as I was searching for a program to 
connect, there was no... or I'm simply too stupid. ;)

My PCICIA Card is a ComOne MC220 56k Modem Card... Its really not the best, I 
know... but even better than nothing! ;)

Is there any possibility to connect with my PCICIA Card Modem? And if yes, 
how?

I recongnized, that plan 9 without Internet is nothing and on my 500 Mhz 
Computer it won't install at all....

Thanks for helping,

TamTam

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

http://javacoffee.de -- "Die Community mit Aroma!"

http://benny-thegame.de.vu -- "Die Offizielle Seite von Benny The Game!"

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

Re: [9fans] PCICIA Modem

[Sascha Retzki]

On Fri, Dec 09, 2005 at 06:40:31PM +0100, TamTam wrote:
> Is there any possibility to connect with my PCICIA Card Modem? And if yes, 
> how?
> 

I don't know how cardbus is handled on Plan9, but I can tell you what
happened when I was plugging such a thing into a NetBSD box - the device
was registered as a 56k-modem connected to the serial port. Maybe
something similar can be done, no idea.

Re: [9fans] PCICIA Modem

[Paweł Lasek]

On 12/9/05, TamTam <javacoffee@gmx.de> wrote:

> My PCICIA Card is a ComOne MC220 56k Modem Card... Its really not the best, I
> know... but even better than nothing! ;)
>
> Is there any possibility to connect with my PCICIA Card Modem? And if yes,
> how?

Check all possible seiral ports - It should register itself as a
standard PCMCIA UART, after all onboard ones. After that you can use
it as any other modem connected to serial port.

> Thanks for helping,

> TamTam
>

--
Paweł Lasek
"Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei
http://plasek.jogger.pl [in polish]

Re: [9fans] PCICIA Modem

[Martin C. Atkins]

On Mon, 12 Dec 2005 16:07:42 +0100 Paweł Lasek <pawel.lasek@gmail.com> wrote:
> On 12/9/05, TamTam <javacoffee@gmx.de> wrote:
> 
> > My PCICIA Card is a ComOne MC220 56k Modem Card... Its really not the best, I
> > know... but even better than nothing! ;)
> >
> > Is there any possibility to connect with my PCICIA Card Modem? And if yes,
> > how?

I've got something with (I believe) the same number (and from the same source - a VAIO).
(I don't have it handy to double check the model number, however)

My modem is a softmodem, and so no, it won't "just" show up as a serial port!
(And I had a good deal of trouble getting it to work under Linux - in fact,
I eventually gave up - the modem worked - eventually, just - but suspend/resume broke it)

Martin

Re: [9fans] PCICIA Modem

[Paweł Lasek]

On 12/26/05, Martin C. Atkins <martin_ml@parvat.com> wrote:

> I've got something with (I believe) the same number (and from the same source - a VAIO).
> (I don't have it handy to double check the model number, however)
> My modem is a softmodem, and so no, it won't "just" show up as a serial port!
> (And I had a good deal of trouble getting it to work under Linux - in fact,
> I eventually gave up - the modem worked - eventually, just - but suspend/resume broke it)

Then it's screwed, I say... If it's soft-modem, the only available
solution is to write a driver for it. However isn't it rather rare for
PCMCIA modems to be soft-modems? At least the one I have is just a
"PCMCIA Serial Port", the same goes for the one mounted on Compaq
Insight/LightsOut PCI which is in my school's Proliant 1850R.


> Martin

Good Luck with making it work on Plan9 (At least none of you seem to
have the problem of Plan9 not booting at all ;-) ( Solution for me:
Run Xen/Linux w/ Plan9 in domain 1 ))

--
Paweł Lasek
"Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei
http://plasek.jogger.pl [in polish]
http://plasek.wordpress.com [in polish]

[9fans] Re: const

[Nikita Danilov]

Ronald G Minnich <rminnich@lanl.gov> writes:

[...]

>
> I think I missed the part of the discussion that explains how to do
> mmap'ed I/O without volatile, and a good idea of how to tweak the

By writing leaf functions in assembly?

Nikita.

Re: [9fans] Re: const

[Russ Cox]

> > I think I missed the part of the discussion that explains how to do
> > mmap'ed I/O without volatile, and a good idea of how to tweak the
>
> By writing leaf functions in assembly?

This is an awful approach.  We have many drivers that
compile unchanged on multiple architectures.  Having to
write them in assembly just because the C compiler is
too clever is just broken.

As I pointed out, we don't have this problem in the
Plan 9 C compilers anyway.  And the people using
smarter-than-thou C compilers like gcc can sprinkle
their code with volatiles.

Russ

Re: [9fans] Re: const

[Ronald G Minnich]

Nikita Danilov wrote:
> Ronald G Minnich <rminnich@lanl.gov> writes:
> 
> [...]
> 
> 
>>I think I missed the part of the discussion that explains how to do
>>mmap'ed I/O without volatile, and a good idea of how to tweak the
> 
> 
> By writing leaf functions in assembly?

yuck. I think that's a bad, bad idea.

ron