> -----Original Message-----
> From: Andrew Boyd [mailto:community-noreply@qnx.com]
> Sent: Monday, September 21, 2009 10:44 AM
> To: technology-networking
> Subject: RE: unmount qnet
> 
> 
> > From: Mario
> >
> > Is there a plan to make qnet unmountable.
> 
> Short history lesson:  Kirk Russell, tester extraordinaire,
> discovered during his incredible stress tests repeatedly
> mounting and umounting qnet as fast as he could, that there
> were windows in the infrastructure with respect to umounting
> protocols (like qnet).
> 
> After considerable internal discussion, the decision was
> made that since the umounting of protocols could not be
> made bulletproof, it simply was not going to be permitted.
> 
> > Changing MTU for QNET is causing grief for us.
> 
> Goodness.  You want to change MTU on the fly?
> 
> Never in a million years did I think anyone would
> need to do that.  Heck, until recently, you couldn't
> even control the MTU from the cmd line (until the option
> was added) - instead, the MTU was retreived from the
> driver for the interface, which seemed sensible at
> the time - the driver ought to know the MTU for it's
> media.

Our system boots with a "default" TCP/IP and QNET config.  This is done within the .boot.  Then the "sysinit" takes over
 and configure the network according to configuration file. This is great because it means that even if the filesystem 
is corrupted or big screw up happens, the system will boot and be reachable via network either with TCP/IP or QNET. 
Customer support group loves this. 

The default config obviously uses the default MTU, then if the configuration file specifies a MTU it is changed, but 
qnet was already mounted.  Instead I guess io-pkt could be restarted from the sysinit instead of trying to modify the 
operating parameter. I'll have to give it more though. 

> 
> --
> aboyd
> 
> 
> 
> 
> _______________________________________________
> 
> Technology
> http://community.qnx.com/sf/go/post38401
>