linux-decnet-user Mailing List for DECnet for Linux
Brought to you by:
chrissie_c,
ph3-der-loewe
Menu
▾
▴
linux-decnet-user — Discussion for users of DECnet on Linux
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(8) |
Jun
(39) |
Jul
(30) |
Aug
(23) |
Sep
(9) |
Oct
(9) |
Nov
(30) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(12) |
Feb
(4) |
Mar
(21) |
Apr
|
May
(3) |
Jun
(3) |
Jul
(13) |
Aug
(13) |
Sep
(18) |
Oct
(10) |
Nov
(25) |
Dec
(2) |
| 2002 |
Jan
(7) |
Feb
(14) |
Mar
(15) |
Apr
(29) |
May
(10) |
Jun
(23) |
Jul
(76) |
Aug
(52) |
Sep
(15) |
Oct
(47) |
Nov
(12) |
Dec
(1) |
| 2003 |
Jan
(5) |
Feb
(12) |
Mar
(21) |
Apr
(26) |
May
(66) |
Jun
(16) |
Jul
(13) |
Aug
(7) |
Sep
(21) |
Oct
(11) |
Nov
(4) |
Dec
(11) |
| 2004 |
Jan
(18) |
Feb
(1) |
Mar
(1) |
Apr
(20) |
May
(10) |
Jun
(4) |
Jul
(9) |
Aug
(9) |
Sep
|
Oct
(5) |
Nov
(13) |
Dec
(8) |
| 2005 |
Jan
(23) |
Feb
(2) |
Mar
(1) |
Apr
|
May
(11) |
Jun
(3) |
Jul
(5) |
Aug
(15) |
Sep
(3) |
Oct
(13) |
Nov
(2) |
Dec
(7) |
| 2006 |
Jan
(5) |
Feb
(8) |
Mar
(6) |
Apr
(6) |
May
|
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
(1) |
May
|
Jun
(5) |
Jul
(7) |
Aug
|
Sep
(7) |
Oct
(7) |
Nov
(4) |
Dec
(2) |
| 2008 |
Jan
(10) |
Feb
(5) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
(14) |
Aug
(3) |
Sep
(6) |
Oct
(7) |
Nov
|
Dec
|
| 2009 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
(3) |
Aug
(15) |
Sep
(9) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2010 |
Jan
|
Feb
(5) |
Mar
(2) |
Apr
|
May
(3) |
Jun
|
Jul
(5) |
Aug
(2) |
Sep
(6) |
Oct
(1) |
Nov
(15) |
Dec
|
| 2011 |
Jan
(4) |
Feb
(1) |
Mar
(11) |
Apr
|
May
|
Jun
(17) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(8) |
| 2012 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(12) |
Feb
(15) |
Mar
(11) |
Apr
(1) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2016 |
Jan
|
Feb
(14) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(1) |
|
2
(1) |
3
(2) |
4
|
5
(1) |
6
(1) |
7
(1) |
8
|
|
9
(2) |
10
(4) |
11
(1) |
12
(1) |
13
|
14
|
15
(2) |
|
16
(1) |
17
|
18
(1) |
19
(2) |
20
(6) |
21
(2) |
22
|
|
23
|
24
|
25
(1) |
26
|
27
|
28
|
29
|
|
30
|
31
|
|
|
|
|
|
|
From: Konstantin G. <gu...@li...> - 2000-07-25 21:05:36
|
Hello!
What does this mean and how to work against it?
Local> c limon
Local -239- Connection to LIMON not established
Number of virtual circuits exceeded
Local>
|
|
From: Mauricio M. <MM...@ex...> - 2000-07-21 20:23:03
|
Thanks for the patch.. It doesn't seem to look like a DAPFS patch though.
As I understand.. DecNET should be in the latest kernel. But no DAPFS
support. Strange.
Maybe I need to know what the newest working kernel & DAPFS combo is.
Thanks for your help,
Mauricio
-----Original Message-----
From: ecc [mailto:ec...@cy...]
Sent: July 21, 2000 3:07 PM
To: Mauricio Mejia
Subject: decnet patch
Mauricio,
Here is the last patch I have in my archive.
It should be in sourceforge somewhere.
Of course disregard if you already have it, as you can see
it is for decnet bug
fixes.
I did not see any reference to dapfs. And I will try it
tonight or tomorrow.
My system is back up (almost), eth0 only comes up when I
insmod the tulip.o
driver
So almost means no decnet yet, as I can not set the mac
address.
I compiled 2.3.42, 2.3.51 yesterday with the dapfs patch and
I do not get the
errors in your message.
I recall compiling the 2.3.42 with it when it was current
but, I can not recall
using dnmount.
Ed
----------------------------------------------------------------------------
-----
diff -r -u linux-2.4.0test1-ac21/include/net/dn.h
linux/include/net/dn.h
--- linux-2.4.0test1-ac21/include/net/dn.h Mon May 1
11:20:00 2000
+++ linux/include/net/dn.h Mon Jun 19 16:56:31 2000
@@ -6,8 +6,8 @@
typedef unsigned short dn_address;
-#define dn_ntohs(x) le16_to_cpu(x)
-#define dn_htons(x) cpu_to_le16(x)
+#define dn_ntohs(x) le16_to_cpu((unsigned short)(x))
+#define dn_htons(x) cpu_to_le16((unsigned short)(x))
struct dn_scp /* Session
Control Port */
{
diff -r -u linux-2.4.0test1-ac21/net/decnet/af_decnet.c
linux/net/decnet/af_decnet.c
--- linux-2.4.0test1-ac21/net/decnet/af_decnet.c Mon
May 1 11:20:06 2000
+++ linux/net/decnet/af_decnet.c Mon Jun 19 16:49:40
2000
@@ -285,7 +285,7 @@
switch(*fmt) {
case 0:
- sdn->sdn_objnum = dn_htons(type);
+ sdn->sdn_objnum = type;
return 2;
case 1:
namel = 16;
@@ -526,10 +526,6 @@
{
struct dn_scp *scp = &sk->protinfo.dn;
- if (sk->dead)
- return;
-
- sk->dead = 1;
scp->nsp_rxtshift = 0; /* reset back off */
if (sk->socket) {
@@ -661,11 +657,12 @@
struct sock *sk = sock->sk;
if (sk) {
+ sock_orphan(sk);
+ sock_hold(sk);
lock_sock(sk);
- sock->sk = NULL;
- sk->socket = NULL;
dn_destroy_sock(sk);
release_sock(sk);
+ sock_put(sk);
}
return 0;
diff -r -u linux-2.4.0test1-ac21/net/decnet/dn_neigh.c
linux/net/decnet/dn_neigh.c
--- linux-2.4.0test1-ac21/net/decnet/dn_neigh.c Fri Mar 3
11:02:06 2000
+++ linux/net/decnet/dn_neigh.c Sun Jun 18 19:16:03 2000
@@ -441,7 +441,7 @@
struct dn_dev *dn_db;
dn_address src;
- src = dn_eth2dn(msg->id);
+ src = dn_htons(dn_eth2dn(msg->id));
neigh = __neigh_lookup(&dn_neigh_table, &src,
skb->dev, 1);
@@ -498,7 +498,7 @@
struct dn_neigh *dn;
dn_address src;
- src = dn_eth2dn(msg->id);
+ src = dn_htons(dn_eth2dn(msg->id));
neigh = __neigh_lookup(&dn_neigh_table, &src,
skb->dev, 1);
diff -r -u linux-2.4.0test1-ac21/net/decnet/dn_route.c
linux/net/decnet/dn_route.c
--- linux-2.4.0test1-ac21/net/decnet/dn_route.c Fri May 12
10:07:22 2000
+++ linux/net/decnet/dn_route.c Mon Jun 19 16:54:00 2000
@@ -131,7 +131,7 @@
return dn_rt_hash_mask & (unsigned)tmp;
}
-static void dn_dst_check_expire(unsigned long dummy)
+static void SMP_TIMER_NAME(dn_dst_check_expire)(unsigned
long dummy)
{
int i;
struct dn_route *rt, **rtp;
@@ -142,10 +142,12 @@
rtp = &dn_rt_hash_table[i].chain;
write_lock(&dn_rt_hash_table[i].lock);
- for(;(rt=*rtp); rtp = &rt->u.rt_next) {
+ while((rt=*rtp) != NULL) {
if (atomic_read(&rt->u.dst.__refcnt)
||
- (now -
rt->u.dst.lastuse) < expire)
+ (now -
rt->u.dst.lastuse) < expire) {
+ rtp = &rt->u.rt_next;
continue;
+ }
*rtp = rt->u.rt_next;
rt->u.rt_next = NULL;
dst_free(&rt->u.dst);
@@ -156,10 +158,11 @@
break;
}
- dn_route_timer.expires = now +
decnet_dst_gc_interval * HZ;
- add_timer(&dn_route_timer);
+ mod_timer(&dn_route_timer, now +
decnet_dst_gc_interval * HZ);
}
+SMP_TIMER_DEFINE(dn_dst_check_expire, dn_dst_task);
+
static int dn_dst_gc(void)
{
struct dn_route *rt, **rtp;
@@ -172,10 +175,12 @@
write_lock_bh(&dn_rt_hash_table[i].lock);
rtp = &dn_rt_hash_table[i].chain;
- for(; (rt=*rtp); rtp = &rt->u.rt_next) {
+ while((rt=*rtp) != NULL) {
if (atomic_read(&rt->u.dst.__refcnt)
||
- (now -
rt->u.dst.lastuse) < expire)
+ (now -
rt->u.dst.lastuse) < expire) {
+ rtp = &rt->u.rt_next;
continue;
+ }
*rtp = rt->u.rt_next;
rt->u.rt_next = NULL;
dst_free(&rt->u.dst);
@@ -229,7 +234,7 @@
write_unlock_bh(&dn_rt_hash_table[hash].lock);
}
-void dn_run_flush(unsigned long dummy)
+void SMP_TIMER_NAME(dn_run_flush)(unsigned long dummy)
{
int i;
struct dn_route *rt, *next;
@@ -250,6 +255,8 @@
write_unlock_bh(&dn_rt_hash_table[i].lock);
}
}
+
+SMP_TIMER_DEFINE(dn_run_flush, dn_flush_task);
static spinlock_t dn_rt_flush_lock = SPIN_LOCK_UNLOCKED;
----------------------------------------------------------------------------
--------
Mauricio Mejia wrote:
> Well I've downloaded kernel 2.3.42 and applied the DAPFS
patch for that
> kernel. The final result was the kernel failing to
compile.
>
> I guess the patch messed up the compile.
>
> Here is a sample of the compile error.
>
> make -C dapfs
> make[2]: Entering directory `/tmp/linux-2.3.42/fs/dapfs'
> make all_targets
> make[3]: Entering directory `/tmp/linux-2.3.42/fs/dapfs'
> gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__
-Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer
-fno-strict-aliasing -pipe
> -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o
inode.o inode.c
> gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__
-Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer
-fno-strict-aliasing -pipe
> -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o
dir.o dir.c
> gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__
-Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer
-fno-strict-aliasing -pipe
> -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o
file.o file.c
> gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__
-Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer
-fno-strict-aliasing -pipe
> -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o
dap_functions.o
> dap_functions.c
> In file included from
/tmp/linux-2.3.42/include/net/dn.h:4,
> from
/tmp/linux-2.3.42/include/net/sock.h:81,
> from dap_functions.c:40:
> /tmp/linux-2.3.42/include/linux/dn.h:68: redefinition of
`struct dn_naddr'
> /tmp/linux-2.3.42/include/linux/dn.h:74: redefinition of
`struct
> sockaddr_dn'
> /tmp/linux-2.3.42/include/linux/dn.h:90: redefinition of
`struct optdata_dn'
> /tmp/linux-2.3.42/include/linux/dn.h:98: redefinition of
`struct
> accessdata_dn'
> In file included from
/tmp/linux-2.3.42/include/net/sock.h:81,
> from dap_functions.c:40:
> /tmp/linux-2.3.42/include/net/dn.h:13: redefinition of
`struct dn_scp'
> make[3]: *** [dap_functions.o] Error 1
> make[3]: Leaving directory `/tmp/linux-2.3.42/fs/dapfs'
> make[2]: *** [first_rule] Error 2
> make[2]: Leaving directory `/tmp/linux-2.3.42/fs/dapfs'
> make[1]: *** [_subdir_dapfs] Error 2
> make[1]: Leaving directory `/tmp/linux-2.3.42/fs'
>
> Any luck finding a newer DAPFS patch? Or anyone get this
one working?
>
> Thanks,
>
> Mauricio
>
> _______________________________________________
> Linux-decnet-user mailing list
> Lin...@li...
>
http://lists.sourceforge.net/mailman/listinfo/linux-decnet-user
|
|
From: ecc <ec...@cy...> - 2000-07-21 01:08:46
|
Mauricio, I have bad news. I bit the big one on this test as I am now down. The compile had a couple of warnings, but it compiled. The warnings were about an implicit declaration of "abs". The system booted, but it wont find my eth0. Too late I remembered having this problem when I moved to 2.3.xx I have a tulip compatible, linksys NIC. I will get the card back to work either tomorow or in the next couple of days. I am compiling 2.3.42 now.... will keep you informed. Ed Calderon ecc... Mauricio Mejia wrote: > Well I've downloaded kernel 2.3.42 and applied the DAPFS patch for that > kernel. The final result was the kernel failing to compile. > > I guess the patch messed up the compile. > > Here is a sample of the compile error. > > make -C dapfs > make[2]: Entering directory `/tmp/linux-2.3.42/fs/dapfs' > make all_targets > make[3]: Entering directory `/tmp/linux-2.3.42/fs/dapfs' > gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o inode.o inode.c > gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o dir.o dir.c > gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o file.o file.c > gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o dap_functions.o > dap_functions.c > In file included from /tmp/linux-2.3.42/include/net/dn.h:4, > from /tmp/linux-2.3.42/include/net/sock.h:81, > from dap_functions.c:40: > /tmp/linux-2.3.42/include/linux/dn.h:68: redefinition of `struct dn_naddr' > /tmp/linux-2.3.42/include/linux/dn.h:74: redefinition of `struct > sockaddr_dn' > /tmp/linux-2.3.42/include/linux/dn.h:90: redefinition of `struct optdata_dn' > /tmp/linux-2.3.42/include/linux/dn.h:98: redefinition of `struct > accessdata_dn' > In file included from /tmp/linux-2.3.42/include/net/sock.h:81, > from dap_functions.c:40: > /tmp/linux-2.3.42/include/net/dn.h:13: redefinition of `struct dn_scp' > make[3]: *** [dap_functions.o] Error 1 > make[3]: Leaving directory `/tmp/linux-2.3.42/fs/dapfs' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory `/tmp/linux-2.3.42/fs/dapfs' > make[1]: *** [_subdir_dapfs] Error 2 > make[1]: Leaving directory `/tmp/linux-2.3.42/fs' > > Any luck finding a newer DAPFS patch? Or anyone get this one working? > > Thanks, > > Mauricio > > _______________________________________________ > Linux-decnet-user mailing list > Lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux-decnet-user |
|
From: ecc <ec...@cy...> - 2000-07-20 22:26:11
|
Mauricio, I have just patched my running kernel linux-2.3.51 with the dapfs_2-3-42.tar.gz The patch was succesfull, I am finishing the compile and will let you know the result. I just wanted to let you know before you go home.(assuming you are at work) Ed Mauricio Mejia wrote: > Well I've downloaded kernel 2.3.42 and applied the DAPFS patch for that > kernel. The final result was the kernel failing to compile. > > I guess the patch messed up the compile. > > Here is a sample of the compile error. > > make -C dapfs > make[2]: Entering directory `/tmp/linux-2.3.42/fs/dapfs' > make all_targets > make[3]: Entering directory `/tmp/linux-2.3.42/fs/dapfs' > gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o inode.o inode.c > gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o dir.o dir.c > gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o file.o file.c > gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o dap_functions.o > dap_functions.c > In file included from /tmp/linux-2.3.42/include/net/dn.h:4, > from /tmp/linux-2.3.42/include/net/sock.h:81, > from dap_functions.c:40: > /tmp/linux-2.3.42/include/linux/dn.h:68: redefinition of `struct dn_naddr' > /tmp/linux-2.3.42/include/linux/dn.h:74: redefinition of `struct > sockaddr_dn' > /tmp/linux-2.3.42/include/linux/dn.h:90: redefinition of `struct optdata_dn' > /tmp/linux-2.3.42/include/linux/dn.h:98: redefinition of `struct > accessdata_dn' > In file included from /tmp/linux-2.3.42/include/net/sock.h:81, > from dap_functions.c:40: > /tmp/linux-2.3.42/include/net/dn.h:13: redefinition of `struct dn_scp' > make[3]: *** [dap_functions.o] Error 1 > make[3]: Leaving directory `/tmp/linux-2.3.42/fs/dapfs' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory `/tmp/linux-2.3.42/fs/dapfs' > make[1]: *** [_subdir_dapfs] Error 2 > make[1]: Leaving directory `/tmp/linux-2.3.42/fs' > > Any luck finding a newer DAPFS patch? Or anyone get this one working? > > Thanks, > > Mauricio > > _______________________________________________ > Linux-decnet-user mailing list > Lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux-decnet-user |
|
From: Mauricio M. <MM...@ex...> - 2000-07-20 15:23:04
|
Well I've downloaded kernel 2.3.42 and applied the DAPFS patch for that
kernel. The final result was the kernel failing to compile.
I guess the patch messed up the compile.
Here is a sample of the compile error.
make -C dapfs
make[2]: Entering directory `/tmp/linux-2.3.42/fs/dapfs'
make all_targets
make[3]: Entering directory `/tmp/linux-2.3.42/fs/dapfs'
gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o inode.o inode.c
gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o dir.o dir.c
gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o file.o file.c
gcc -D__KERNEL__ -I/tmp/linux-2.3.42/include -D__SMP__ -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-DCPU=586 -march=i586 -Wno-unused -Wno-unused -c -o dap_functions.o
dap_functions.c
In file included from /tmp/linux-2.3.42/include/net/dn.h:4,
from /tmp/linux-2.3.42/include/net/sock.h:81,
from dap_functions.c:40:
/tmp/linux-2.3.42/include/linux/dn.h:68: redefinition of `struct dn_naddr'
/tmp/linux-2.3.42/include/linux/dn.h:74: redefinition of `struct
sockaddr_dn'
/tmp/linux-2.3.42/include/linux/dn.h:90: redefinition of `struct optdata_dn'
/tmp/linux-2.3.42/include/linux/dn.h:98: redefinition of `struct
accessdata_dn'
In file included from /tmp/linux-2.3.42/include/net/sock.h:81,
from dap_functions.c:40:
/tmp/linux-2.3.42/include/net/dn.h:13: redefinition of `struct dn_scp'
make[3]: *** [dap_functions.o] Error 1
make[3]: Leaving directory `/tmp/linux-2.3.42/fs/dapfs'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/tmp/linux-2.3.42/fs/dapfs'
make[1]: *** [_subdir_dapfs] Error 2
make[1]: Leaving directory `/tmp/linux-2.3.42/fs'
Any luck finding a newer DAPFS patch? Or anyone get this one working?
Thanks,
Mauricio
|
|
From: ecc <ec...@cy...> - 2000-07-20 14:23:02
|
I have reviewed some messages. Eduardo had a DAPFS patch for 2.3.99-pre5, Steve submitted it for the next kernel release. There was a message from someone in the kerrnel group, acknowledging receipt after Steve made some suggested chnages. Sooo... I would fire up my 2.3.99-pre5 and try that patch. I have not been able to test past 2.3.99-pre7, if I remember correctly. My system will lock up beyond rebooting if I use decnet. I actually have to press reset, the problem was not always immediate, but it never failed. I can not compile the 2.4.0-testx as I get a compilation error at traps.c, however I did not see the DAPFS option in network file systems. Here is a message from Steve Whitehouse if you really want DAPFS: > > > 1. Get 2.3.43 and patch it with dapfs and backport the DECnet bug > > >fixes from the latest kernels _or_ > > > 2. Get the latest kernel and fix dapfs to work with the newer VFS > > > functions > > > If you select option two, then please send in the patches to us :-) Here is a message from Eduardo Serrat: > > >I wrote dapfs for kernel 2.3.99-pre5. > > >Steve: Did you write the patch I suggested for the DECnet kernel? > > >As soon as I have it I will release the new dapfs patch for kernel 2.3.99. > > >Eduardo Ed Calderon ecc... Mauricio Mejia wrote: > I couldn't find a DAPFS patch for 2.3.49... The newest DAPFS patch I could > find was 2.3.42 > > I'll give that a try.. If anyone has a newer patch for DAPFS. Could you > please e-mail it to mm...@hs... <mailto:mm...@hs...> ? > > Thanks! > > Mauricio > > -----Original Message----- > From: Mauricio Mejia [mailto:MM...@ex...] > Sent: July 20, 2000 8:25 AM > To: 'Patrick Caulfield' > Cc: 'lin...@li...' > Subject: RE: [Linux-decnet-user] Help with DNMOUNT > > Sounds good.. I'll go grab a 2.3 kernel that matches the > latest dapfs patch > on that page. > > I'll let you know if I am sucessful. > > Mauricio > > -----Original Message----- > From: 'Patrick Caulfield' > [mailto:pa...@pa...] > Sent: July 20, 2000 3:04 AM > To: Mauricio Mejia > Cc: > 'lin...@li...' > Subject: Re: [Linux-decnet-user] Help > with DNMOUNT > > On Wed, Jul 19, 2000 at 02:37:24PM -0500, > Mauricio Mejia > wrote: > > I'd be happy even if I could get it > working under 2.3.49. > Is there a DecNET > > and DAPFS patch for this kernel? Where can > I get them? > > > > I'd be willing to test this out. Since we > have a need for > mounting VMS > > disks on the Linux box > > DECnet is built into the 2.3 kernels so > that's easy. the > dapfs patch is on > the download page at > http://linux-decnet.sourceforge.net/download.html > > patrick > > _______________________________________________ > Linux-decnet-user mailing list > Lin...@li... > > http://lists.sourceforge.net/mailman/listinfo/linux-decnet-user > > _______________________________________________ > Linux-decnet-user mailing list > Lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux-decnet-user |
|
From: Mauricio M. <MM...@ex...> - 2000-07-20 13:46:53
|
I couldn't find a DAPFS patch for 2.3.49... The newest DAPFS patch I could find was 2.3.42 I'll give that a try.. If anyone has a newer patch for DAPFS. Could you please e-mail it to mm...@hs... <mailto:mm...@hs...> ? Thanks! Mauricio -----Original Message----- From: Mauricio Mejia [mailto:MM...@ex...] Sent: July 20, 2000 8:25 AM To: 'Patrick Caulfield' Cc: 'lin...@li...' Subject: RE: [Linux-decnet-user] Help with DNMOUNT Sounds good.. I'll go grab a 2.3 kernel that matches the latest dapfs patch on that page. I'll let you know if I am sucessful. Mauricio -----Original Message----- From: 'Patrick Caulfield' [mailto:pa...@pa...] Sent: July 20, 2000 3:04 AM To: Mauricio Mejia Cc: 'lin...@li...' Subject: Re: [Linux-decnet-user] Help with DNMOUNT On Wed, Jul 19, 2000 at 02:37:24PM -0500, Mauricio Mejia wrote: > I'd be happy even if I could get it working under 2.3.49. Is there a DecNET > and DAPFS patch for this kernel? Where can I get them? > > I'd be willing to test this out. Since we have a need for mounting VMS > disks on the Linux box DECnet is built into the 2.3 kernels so that's easy. the dapfs patch is on the download page at http://linux-decnet.sourceforge.net/download.html patrick _______________________________________________ Linux-decnet-user mailing list Lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux-decnet-user |
|
From: Mauricio M. <MM...@ex...> - 2000-07-20 13:21:10
|
Sounds good.. I'll go grab a 2.3 kernel that matches the latest dapfs patch on that page. I'll let you know if I am sucessful. Mauricio -----Original Message----- From: 'Patrick Caulfield' [mailto:pa...@pa...] Sent: July 20, 2000 3:04 AM To: Mauricio Mejia Cc: 'lin...@li...' Subject: Re: [Linux-decnet-user] Help with DNMOUNT On Wed, Jul 19, 2000 at 02:37:24PM -0500, Mauricio Mejia wrote: > I'd be happy even if I could get it working under 2.3.49. Is there a DecNET > and DAPFS patch for this kernel? Where can I get them? > > I'd be willing to test this out. Since we have a need for mounting VMS > disks on the Linux box DECnet is built into the 2.3 kernels so that's easy. the dapfs patch is on the download page at http://linux-decnet.sourceforge.net/download.html patrick |
|
From: 'Patrick Caulfield' <pa...@pa...> - 2000-07-20 08:00:32
|
On Wed, Jul 19, 2000 at 02:37:24PM -0500, Mauricio Mejia wrote: > I'd be happy even if I could get it working under 2.3.49. Is there a DecNET > and DAPFS patch for this kernel? Where can I get them? > > I'd be willing to test this out. Since we have a need for mounting VMS > disks on the Linux box DECnet is built into the 2.3 kernels so that's easy. the dapfs patch is on the download page at http://linux-decnet.sourceforge.net/download.html patrick |
|
From: Mauricio M. <MM...@ex...> - 2000-07-19 19:34:09
|
I'd be happy even if I could get it working under 2.3.49. Is there a DecNET and DAPFS patch for this kernel? Where can I get them? I'd be willing to test this out. Since we have a need for mounting VMS disks on the Linux box Thanks for any information you can provide. Mauricio -----Original Message----- From: Patrick Caulfield [mailto:pa...@pa...] Sent: July 19, 2000 12:42 PM To: Mauricio Mejia Cc: 'lin...@li...' Subject: Re: [Linux-decnet-user] Help with DNMOUNT On Tue, Jul 18, 2000 at 10:19:22AM -0500, Mauricio Mejia wrote: > I have installed the new kernel (2.2.16) and applied the new patch for that > version. I've tested out the DecNET for Linux mounting feature again.. and > I'm getting the same results. All the DecNET programs such as dndir work > properly, except we have the same problems with dnmount. > Yes, I'm afraid no work has happened on the DAPFS for kernel 2.2 for ages. AFAIK the only one that actually works was Eduardo's 2.3.49 version but that doesn't patch into the new 2.4 kernels nor the old 2.2 ones! Volunteers please....! Patrick |
|
From: Patrick C. <pa...@pa...> - 2000-07-19 18:08:27
|
On Tue, Jul 18, 2000 at 10:19:22AM -0500, Mauricio Mejia wrote: > I have installed the new kernel (2.2.16) and applied the new patch for that > version. I've tested out the DecNET for Linux mounting feature again.. and > I'm getting the same results. All the DecNET programs such as dndir work > properly, except we have the same problems with dnmount. > Yes, I'm afraid no work has happened on the DAPFS for kernel 2.2 for ages. AFAIK the only one that actually works was Eduardo's 2.3.49 version but that doesn't patch into the new 2.4 kernels nor the old 2.2 ones! Volunteers please....! Patrick |
|
From: Mauricio M. <MM...@ex...> - 2000-07-18 15:16:05
|
I have installed the new kernel (2.2.16) and applied the new patch for that version. I've tested out the DecNET for Linux mounting feature again.. and I'm getting the same results. All the DecNET programs such as dndir work properly, except we have the same problems with dnmount. By the way.. I'm using DNPROGS v2.05 (3 Apr 2000) [root@cis-lnxserv /root]# cat /etc/decnet.conf # # DECnet hosts file # #Node Node Name Node Line Line #Type Address Tag Name Tag Device #----- ------- ----- ----- ----- ------ executor 1.200 name linux1 line eth0 node 1.17 name alpha1 line eth0 node 1.18 name alpha2 line eth0 node 1.19 name alpha3 line eth0 node 1.16 name alpha6 line eth0 node 1.14 name alpha7 line eth0 node 1.15 name alpha8 line eth0 I've used TCPDUMP to capture all packets going to ALPHA1 (1.17) and here is what I found. I don't understand the TCP dump very well. I've included a DNDIR dump.. (which worked fine) and then the DNMOUNT, LS -LA and then the UMOUNT. Let me know if you understand any of this.. thanks! [root@cis-lnxserv /root]# tcpdump decnet host 1.17 -vv DNDIR 'alpha1"user password"::dsa342:[mmejia]' 09:01:08.469666 eth0 < [pad:1] 1.17 > 1.200 25 IE 0 hops conn-ack 8209 09:01:08.500052 eth0 < [pad:1] 1.17 > 1.200 32 IE 0 hops conn-confirm 8434>8209 ver 4.1 segsize 1459 09:01:08.500520 eth0 < [pad:1] 1.17 > 1.200 33 IE 0 hops link-service 8434>8209 ack 1 seg 1 dat seg count 0 09:01:08.501172 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops data-ack 8434>8209 ack 1 09:01:08.501353 eth0 < [pad:1] 1.17 > 1.200 52 IE 0 hops data 8434>8209 ack 1 seg 1 09:01:08.503644 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops data-ack 8434>8209 ack 2 09:01:08.703948 eth0 < [pad:1] 1.17 > 1.200 1490 IE 0 hops data 8434>8209 ack 2 seg 2 09:01:08.705197 eth0 < [pad:1] 1.17 > 1.200 1490 IE 0 hops data 8434>8209 ack 2 seg 3 09:01:08.706495 eth0 < [pad:1] 1.17 > 1.200 1490 IE 0 hops data 8434>8209 ack 2 seg 4 09:01:08.707499 eth0 < [pad:1] 1.17 > 1.200 1150 IE 0 hops data 8434>8209 ack 2 seg 5 09:01:08.736600 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops disconn-confirm 8434>8209 disconnect complete DNMOUNT 'alpha1"user password"::dsa342:[userdir]' /mnt/alpha 09:03:26.465768 eth0 < [pad:1] 1.17 > 1.200 25 IE 0 hops conn-ack 8210 09:03:26.582507 eth0 < [pad:1] 1.17 > 1.200 32 IE 0 hops conn-confirm 8439>8210 ver 4.1 segsize 1459 09:03:26.582962 eth0 < [pad:1] 1.17 > 1.200 33 IE 0 hops link-service 8439>8210 ack 1 seg 1 dat seg count 0 09:03:26.585938 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops data-ack 8439>8210 ack 1 09:03:26.586174 eth0 < [pad:1] 1.17 > 1.200 52 IE 0 hops data 8439>8210 ack 1 seg 1 09:03:35.582262 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops ils-ack 8439>8210 ack 2 09:03:44.582272 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops ils-ack 8439>8210 ack 3 09:03:53.582441 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops ils-ack 8439>8210 ack 4 09:04:02.582226 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops ils-ack 8439>8210 ack 5 LS -LA /tmp/alpha (no packets sent) 09:04:11.582230 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops ils-ack 8439>8210 ack 6 09:04:20.582226 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops ils-ack 8439>8210 ack 7 09:04:29.582251 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops ils-ack 8439>8210 ack 8 UMOUNT /mnt/alpha 09:04:30.391615 eth0 < [pad:1] 1.17 > 1.200 29 IE 0 hops disconn-confirm 8439>8210 disconnect complete I have noticed that while the LS -LA is active I see the 2nd connection that is listed below. The Remote Node 0.00. I'm wondering if it has something to do with the DefRoute being 0.0??? How do I set the routine? Maybe I have something configured wrong? Here is a list of cat /proc/net/decnet (while the LS -LA is waiting for a response) Executor Device DefRoute 1.200 eth0 0.0 Remote Source Remote Object Link Data Packets Link Packets Node Port Port Number State Out In Out In 1.17 2015 4167 17 RUN 2 1 6 1 0.0 2017 0000 CI 1 0 1 0 Thanks for any help you can provide, Mauricio Mejia Mm...@hs... <mailto:Mm...@hs...> Winnipeg, Manitoba Canada |
|
From: Patrick C. <pa...@pa...> - 2000-07-16 13:30:11
|
On Sat, Jul 15, 2000 at 04:41:15PM -0400, Gregg C Levine wrote: > Hello from Gregg C Levine usually with Jedi Knight Computers > A longish time ago, before I started this company, I had to repair an IBM > PC/AT, it was wearing a DECNET for PCs card, to wit a DEPCA card, or board. > Does support for it, exist within the Linux-Decnet community? Oh, and the > PC/AT lived, it needed to have DOS reinstalled on its harddrive. Nothing > really wrong there, just that the user was a bit clumsy. The DEPCA is supported under Linux so I see no reason why DECnet wouldn't work on it. patrick |
|
From: Gregg C L. <han...@wo...> - 2000-07-15 20:41:50
|
Hello from Gregg C Levine usually with Jedi Knight Computers A longish time ago, before I started this company, I had to repair an IBM PC/AT, it was wearing a DECNET for PCs card, to wit a DEPCA card, or board. Does support for it, exist within the Linux-Decnet community? Oh, and the PC/AT lived, it needed to have DOS reinstalled on its harddrive. Nothing really wrong there, just that the user was a bit clumsy. -- Gregg C Levine mailto:han...@wo... "Use the Force, Luke." Obi-Wan Kenobi "Trust in the Force, Luke, and wait." Obi-Wan Kenobi "The Force will be with you. Always. " Obi-Wan Kenobi "May the Force be with you." "And to you" Anonymous |
|
From: Akihiko T. <TAN...@sp...> - 2000-07-15 16:14:03
|
I've installed Red Hat V6.2 on Pentium I PC. I am new to Linux and I am trying to figure out how to write to a serial port (COM1) in C/C++. My background is OpenVMS/VAX. With OpenVMS, assign an I/O channel ( sys$assign() ) and issue QIOW with IO$_WRITEVBLK ( sys$qiow() ). What are equivalent to these OpenVMS functions in Linux platform? What is the Lunix device name of COM1? Akihiko |
|
From: Patrick C. <pa...@pa...> - 2000-07-12 16:31:16
|
I've set up a web page about LAT to help give an overview of what it does and how to use it. http://linux-decnet.sourceforge.net/lat.html Let me know if you find any errors or have any suggestions for it. I've also added latd sources to the download page to avoid any confusion. Patrick |
|
From: Patrick C. <pa...@pa...> - 2000-07-11 15:54:44
|
I am please to announce a new kernel patch against Linux 2.2.16. This fixes two problems as well as being a clean patch against 2.2.16: - The delay in disconnecting from Phase V nodes is fixed - The message "protocol 0360 is buggy" has gone See http://linux-decnet.sourceforge.net/download.html or ftp://linux-decnet.sourceforge.net/pub/linux-decnet/dnk226.tgz Patrick |
|
From: Kenn H. <ke...@li...> - 2000-07-10 19:13:00
|
On Mon, Jul 10, 2000 at 02:31:49PM -0400, Paul Koning wrote: > Note that DECnet phase 5, or whatever they call it, is supposed to > include backwards compatibility with phase 4. So if you need to talk > to a DECnet/Linux box (which is phase 4) that is supposed to work. > Give or take bugs, of course, as usual. But unlike certain other well > known software vendors, DEC has always made backwards compatibility a > non-negotiable software requirement. You can sing it! I remember hearing that DEC used .EXEs linked on VMS v1.0 as part of the regression test suite for each new release of VMS. They even managed to move from 9.3 file names to 32.32 without much grief, unlike some other compan~1. Later, Kenn |
|
From: Paul K. <pk...@xe...> - 2000-07-10 18:37:12
|
Note that DECnet phase 5, or whatever they call it, is supposed to include backwards compatibility with phase 4. So if you need to talk to a DECnet/Linux box (which is phase 4) that is supposed to work. Give or take bugs, of course, as usual. But unlike certain other well known software vendors, DEC has always made backwards compatibility a non-negotiable software requirement. paul |
|
From: Paul K. <pk...@xe...> - 2000-07-10 15:51:14
|
>>>>> "Patrick" == Patrick Caulfield <pa...@pa...> writes: Patrick> On Mon, Jun 26, 2000 at 11:51:52PM +0100, Kenn Humborg Patrick> wrote: >> On Sun, Jun 25, 2000 at 01:04:38PM +0100, Patrick Caulfield wrote: >> > I am pleased to annouce the release of LATD 0.8. > > This >> release is feature-complete for 1.0 so please report any bugs you >> find - > the plan is to do a bug-fix 0.9 and then release a 1.0 >> shortly afterwards > depending on how many problems people find. >> >> I've been wondering... LAT looks like a fairly simple protocol. >> The most 'innovative' element seems to be the way it reduce LAN >> traffic my aggregating users' keystrokes for sessions going to the >> same host (if I understand it correctly). >> >> Why were they so insistent on keeping it proprietary? >> >> Patrick, have you discovered any deeper meaning to all of this? Patrick> Not really. I have been searching the patent archives for Patrick> DEC's terminal server entries and one is just a description Patrick> of a terminal server in general and one concerns the "slot" Patrick> system in use by LAT. Of course it had to be a simple Patrick> protocol because there was not enough memory or CPU power in Patrick> a DECserver 100 to fit a complicated one into ! Patrick> I can understand why it was kept proprietary - it was just Patrick> the prevailing mood at the time. But the patents make no Patrick> more sense to me that any other of the "obvious" patents Patrick> that the US office grants so freely :-( I can see a bunch of points to comment on here. Take these from one who was near the origin of all this stuff but not involved first-hand. LAT started as an advanced development exercise, driven by dissatisfaction with the high complexity and low performance of CTERM. A consideration was the target platform: a device called "Pluto" (yes, quite a dog...) which was a 19 inch rack, about 15 inches high, with a PDP11/23 processor, an Ethernet NIC, and assorted other stuff. Bruce Mann said "there has to be a better way". Part of why LAT looks the way it does is a religious conviction that everything should be done in one layer. I don't agree with that one; if LAT had run over UDP that would have been a good thing. Then again, internet protocols hadn't become the world-conquering force yet at that time as they are now. LAT slots are there because a typical terminal server message (especially server to host) only contains about one or two characters of payload. With a multiport server (64 ports was considered a very sensible target) muxing several input streams into a single packet significantly improves things, because you get more payload per packet interrupt. And packet interrupts are expensive, always have been -- especially back then in the early 1980s. Patents: I will be the first to agree about junk patents but I don't think that applies here. There certainly are more impressive patents, but I think calling this notion "non-obvious and innovative" is reasonable enough (again, remember, early 1980s...) Finally, why is the protocol proprietary? I have no idea. Possibly because that was the norm at the time. DECnet was quite exceptional by the rules of the late 1970s, early 1980s, by having open specs and free permission for anyone to implement. I think the decision went "LAT isn't part of DECnet (correct) so we don't have to open it up, so let's not." DECservers were very popular and rather profitable little boxes, and I suspect the decision may have helped DEC's bottom line for a number of years. In the long run, it hurt because everyone else moved to Telnet, even though Telnet is drastically less efficient. Incidentally, the slot concept of LAT re-materialized in ATM AAL2, used with voice over ATM. I don't know if the creators of that spec realize they copied it, or acknowledged the prior art... paul |
|
From: Patrick C. <pa...@pa...> - 2000-07-10 09:28:20
|
On Fri, Jul 07, 2000 at 11:49:10AM -0500, Mauricio Mejia wrote: > I've been away for a bit and now have a bit more time to play with this > DecNet for Linux. > > Could someone point me in the right direction? Where can I find the latest > DecNet kernel /w DAPFS? > > I need to use DNMOUNT to work with a remote VMS disk. If you need dnmount then the 2.3.43 patch is the ony one that really seems to work AFAICT. Has anyone tried this against the 2.4test kernels?? patrick |
|
From: Rob D. <rob...@in...> - 2000-07-09 23:36:17
|
> I'm getting my networked VAX back in shape again after upgrading > to VMS 7.2. TCP/IP is sorted, but I'm not sure whether I should > install DECnet Phase IV or DECnet Plus? > > DECnet Phase IV has the advantage that I know a little bit about > the NCP commands to manage it, but the disadvantage that there is > no documentation on the OpenVMS website any more. > > DECnet Plus has the advantage of available docs, but I remember > hearing wails of anguish from system managers on comp.os.vms > when they had to upgrade to DECnet Plus and deal with NCL. I've been working with DECnet Phase V ( also known as DECnet/OSI, and currently called DECnet Plus ... next rename scheduled for 2001 ... ;-) ) since 1991, and once you get used to the new syntax of NCL, you find you can't live without the superior control and level of information you are provided with over the old DECnetIV NCP commands. Amongst other things, it also fully supports dual-homed systems, and you get up to 65535 areas (unless you need to talk to DECnetIV systems, in which case you are stuck with the old 63 areas) ... Go with DECnet Plus if you don't have any reason forcing you to stay with DECnetIV ... Rob. |
|
From: Kenn H. <ke...@li...> - 2000-07-09 21:01:28
|
I'm getting my networked VAX back in shape again after upgrading to VMS 7.2. TCP/IP is sorted, but I'm not sure whether I should install DECnet Phase IV or DECnet Plus? DECnet Phase IV has the advantage that I know a little bit about the NCP commands to manage it, but the disadvantage that there is no documentation on the OpenVMS website any more. DECnet Plus has the advantage of available docs, but I remember hearing wails of anguish from system managers on comp.os.vms when they had to upgrade to DECnet Plus and deal with NCL. Any opinions either way? Later, Kenn |
|
From: Mauricio M. <MM...@ex...> - 2000-07-07 16:51:02
|
I've been away for a bit and now have a bit more time to play with this DecNet for Linux. Could someone point me in the right direction? Where can I find the latest DecNet kernel /w DAPFS? I need to use DNMOUNT to work with a remote VMS disk. Thanks for any help you can provide. Mauricio |
|
From: Patrick C. <pa...@pa...> - 2000-07-06 10:47:22
|
>I haven't been able to play with this properly yet, due to a lack of cabling >(which will be fixed soon). However, a couple of questions: > >1. Is it possible to send a BREAK out the DECserver port? Probably not - I'll look into it. >2. If I change the baud rate (and other characteristics) of the > /dev/lat/XXX pty, will these changes be applied to the DECserver > port, or just ignored? It will be ignored. The /dev/lat devices are just symlinks to pseudo-TTYs so I'm not even sure if you can change those things on a slave PTY and have the master know about it. Something else to look at! Patrick |
