If "authors" is referring to me, I have no objection, not only because I know nothing of this code (and trust your opinion, Dave) but that I think having a TCP/IP capability in the core LiS distribution is just as important strategically as some of the other things that are there (some of which I added).
As far as use of major numbers is concerned, the FIFO driver is configured by default to use two majors, but mostly as a demonstration that the driver can use multiple majors if necessary. So, my thought is that it might use a hybrid of your suggestion, e.g., have one predefined major, and if it runs out of minors, another major could be dynamically allocated using the method you suggest.
I.e., the FIFO driver really only needs one, to support associating dynamic loading of the driver instead of modprobe'ing it, and any others that exist are for all intents and purposes the same as that one.
If you look at the code, you'll see that the driver builds a pool of minor devices, and is not otherwise (very) dependent on what major numbers are used. I had been thinking it might be nice at some point to maintain this pool more dynamically so that it doesn't tie up resources not being used, and dynamically allocating new majors past a first would fit with that.
If the situation with Brian's TCP is semantically similar, then a consistent method might be applied to both FIFO and TCP, and thus use only two predefined majors total instead of four.
Even if the need is for semantically different minors, I've used the same approach outside of LiS to limit the use of majors, so it is still workable, but will require more sophisticated organization of the minor numbers (which is not easy in 8 bits...). Who knows - some clever person might even come up with a scheme to allow LiS to use only the single high-level major number as a predefined one, and make them all dynamic otherwise (I have the beginnings of such a scheme in mind, though I don't remember if it was me or someone else who added that high-level major number).
So, my thought is to work it in, and add the issue of LiS' use of major numbers as a new one to be explored more generally (e.g., like locking, SMP, etc.).
(I'm not looking at code as I write this, so consider this just a thought to be further explored...)
-John
David Grothe wrote:
Brian:
Would you have any problems with my working "your" tcp-0.5 into the LiS distribution? I think that I could just untar it under the main LiS directory and visit it in the master Makefile. You can always send me a link to the tgz for an update and I can untar it into this directory. I'll coordinate with you if I want to change anything.
Do any of the other authors like or dislike this idea as well? The only down side that I can see is that it will consume two major device numbers. I could make it allocate its own nodes when activated so that the majors got allocated dynamically. But then you couldn't cause the driver to load just by opening /dev/tcp. You would have to modprobe streams-sock-inet in order for it to perform the mknods internally.
Also, in eyeballing inet.c I found the following at line 1677. Should that first line be deleted as redundant?
if (endp->sock->type == SOCK_STREAM)
if (req->CONIND_number != 0 && endp->sock->type == SOCK_STREAM) {
err = endp->sock->ops->listen(endp->sock, req->CONIND_number);
ERRA("listen issued : res %d", err); ASSERT(err == 0); /*endp->sock->flags |= SO_ACCEPTCON;*/ }
Thanks, Dave
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
.
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
