Setkey problem...

[root at spdyne.UUCP]

>I wrote:
>> 
>> 
>> Greetings,
>> 
>>     I have sent this 8 ways to try to get it into uport... INCLUDING
>> directly connecting to uport!  No response...
>
>My guess is that are in fact not reaching a read account.  Are you using the
>"techs" account or are you going direct?  Microport does reply to mail or
>else they would see a lot more of this type of flame.  (Which was quite common
>not all that long ago.)
>

    Well, I sent it to the following accounts: techs, plocher, jmsully.
    all at uport, with no luck.. (this was a couple of months ago, and
    I was giving them time to respond, not knowing how overloaded their
    time may be...)


Refering to the original question:  (Setkey)
>
>I feel (as apparently so does Microport) that an ioctl to one console device
>should not affect ALL console devices.  (Just as NDELAY on ttys should affect
>only the tty set with NDELAY and not all ttys or even all fds open to that tty.)
>
>This behavior (albeit not exactly what you had in mind) is correct and should
>stay the way it is.  (How difficult is it to simulate using what is correct
>behavior to make things be the way you want?  My guess is a three line shell
>script.)
>
>Good luck.
>   David F. Carlson, Micropen, Inc.


    Did I miss something here?  You say that executing login on a DIFFERENT
console terminal SHOULD Zap all of the setkey assignments on the console and
every other /dev/cons*?!!?   And the back it up with some something about
ONLY affecting the ONE console device that it was executed on??  I don't
understand. Did you understand my original question?

I think that it should work AS DOCUMENTED: if executed on the console it
will affect all consoles, if executed on a virt. console, it will affect
ONLY that console.

    After some more checking, I found that if you execute setkey -d on
any console, it will clear all of them.  It seems that the other bug
that I had, namely that reassigning a key that was once assigned causing
it to scramble all of the assignments, no longer is a problem. (Now that
I have upgraded to 3.0E.  To fix the problem with it scrambling the 
assignments, I had a setkey -d in my .login (Before all of the other
setkey's, I have fixed this by only executing setkey on the console.. but..
it still is broken.)

    -Chert Pellett