PATCHES: Release Suggestion

[okuyamak at dd.iij4u.or.jp]

>>>>> "JA" == Jeremy Allison <jeremy at valinux.com> writes:
JA> I know about the "more bodies doesn't help" problem, but
JA> as for integrating patches rather than large amounts of new
JA> code, it actually does help.

I can't agree with you about this.

I mean, "integerating patches" than "large amounts of new code" is
happening because you don't stop. Nobody is good at shooting moving
target. So, everbody have to make pin-point patch, which will make
partial performance better, but will not make total design better.
But that's all they can do. Making global change requires more time
than making partial patch, and who want to create global, but out of
date change?

# Since statcache is one of the easy to understand global changes,
# I'd like to point different part.
#
# Ex.: I know that current Samba is replying slowly against
#      clients request. This is because current Samba is doing
#      1) recieve ENTIRE request,
#      2) do what ever is required on reply,
#      3) then actually send reply.
#      But if you focus on step 2, you'll find there are many
#      things you can do only with first 4 bytes ( if you
#      do not run construt_reply_common() before switch_message() ).
#
#      This change require global change, for each reply_*() function
#      is required to have parameter of
#      i) file descriptor against Client for recieving rest part of
#         request later.
#      ii) input buffer, it's size, already recieved size, and
#          size it should recieve.
#      iii) output buffer, it's size.
#      And also, each reply_*() should be changed.
#
#      This will make samba to work lot better, because of two reason:
#      1) while you're running into individual reply function,
#         there's high possibility of next packet arriving.
#         If client sends request with 100Mbps ethernet,
#         2nd IP packet for the request will arrive within 1/7300 sec.
#         which is about 1.3msec. If it's 1Gbps, then it's 130usec.
#         this is small enough amount of time to wait with doing
#         something else, instead of simply calling recv()/read()
#         and ask for blocking inside ( once you ask for blocking,
#         unix system usually will not araise you for 10msec, you
#         know ).
#      2) If request was something like SMBwrite, now we can call
#         transfer_file() from first packet. And since transfer_file()
#         can be implemented using sendfile() system call, we can have
#         better scheduling against kernel ( well, if you have
#         sendfile() as system call, though )
#
#      But this entire is change aginst framework, it effects all
#      rpc reply functions, and since so, we can't shoot that large,
#      still increasing, reply functions. So we can't make change against
#      the part.


JA> We don't have the
JA> luxury of ignoring new features, not now we're needing to
JA> integrate better with Win2k. The pressure for new features 
JA> was what the TNG fork was about.

And I think TNG fork was nothing more then stupid idea, because
to add more and more functionality, and that in quick, you need
to have good common structure, which we don't have one.

# And that's another reason why I think we can stop. I can give you
# an oracle that TNG people will succeed in adding first 10
# function, quicker than we do, but then, schdule start slipping for
# 11th, 12th, etc. because of this ugly bases they're standing on.
#
# We don't need to care about foundation we're on, if we are to
# create flat. But if we are to create skyscraper on land like Tokyo,
# where many earth quake (from Microsoft) occur, we first have to
# care about foundation. And foundation can't be changed without
# stop building skyscraper for once.
#
# And changing foundation after skyscraper are being build, is
# lot more harder ( hyper linearly harder ) than changing
# foundation while we're not making things tall enough.
---- 
Kenichi Okuyama at Tokyo Research Lab, IBM-Japan, Co.