Hello! Quoting r. Roland Dreier ([EMAIL PROTECTED]) "Re: [openib-general] Some Missing Features from mthca/user MAD access": > > Yes, I think it is. It involves catching CTRL-C in the application > > and other such horror, and it never works 100%. > > And what about running to opensms on the same HCA? > > I think it is clearly kernel's job to handle synchronisation and do cleanups > > when application exits. > > OK, we can have a file for controlling capability bits. > > > After consideration, I think the proper way is add a reference count > > and clean is_sm when it falls to 0. > > This way runnning two opensms on the same HCA and two different > > HCAs in the same subnet behaves the same. > > I don't understand this. IsSM is per-port, so what does it mean for the > reference count of IsSM for a port to be 2? Two SMs are running on that > port?
I am trying to say it could be transparent. you could be running two sms and it could work more or less. So for example opensm hangs. If I kill it, it will clear the is_sm bit, *but* I dont want that. The way to do it cold be to start a new one, then kill the old one. If userspace wants exclusivity there are standard interfaces for this like flock , we should nto enforce policty I think. > > To do this, I think either and ioctl on umad, or > > a flag to open to set this bit is not too bad though. > > I don't like either the ioctl() or a magic flag for open(). I'm > trying to decide > between a special issm file, or changing the umad file interface to put a > command code in the structure that is passed via write() (this would also > let us add a mechanism for canceling MADs). > > - R. issm file lets you get the current issm status and so find out if someone is running sm, in a clean way. So I am for it. "everything is a file". MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
