* samba/tests/summary.c: Remove. The test is now included ...
* samba/configure.in: ... here. * samba/tests/README: Remove, it's irrelevant. * samba/architecture.doc: Likewise. * samba/include/dlinklist.h: Remove, it's unused. Adjust dependencies. * samba/libsmb/namequery.c (): Remove, it's unused. * Makefile.am: Remove unused Samba files.
Этот коммит содержится в:
Pavel Roskin
родитель
c037f013a3
Коммит
a64b930445
@ -61,7 +61,6 @@ dist-hook:
|
||||
$(mkinstalldirs) $(distdir)/samba/lib
|
||||
$(mkinstalldirs) $(distdir)/samba/libsmb
|
||||
$(mkinstalldirs) $(distdir)/samba/param
|
||||
$(mkinstalldirs) $(distdir)/samba/tests
|
||||
for I in $(SAMBA_DIST); do \
|
||||
cp -p $(srcdir)/samba/$$I $(distdir)/samba/$$I || exit 1; \
|
||||
done
|
||||
@ -104,7 +103,6 @@ mcserv_LDADD = $(MCSERVLIBS)
|
||||
SAMBA_DIST = \
|
||||
Makefile.in \
|
||||
aclocal.m4 \
|
||||
architecture.doc \
|
||||
configure.in \
|
||||
configure \
|
||||
internals.doc \
|
||||
@ -151,7 +149,5 @@ SAMBA_DIST = \
|
||||
libsmb/smbencrypt.c \
|
||||
libsmb/smberr.c \
|
||||
param/loadparm.c \
|
||||
param/params.c \
|
||||
tests/README \
|
||||
tests/summary.c
|
||||
param/params.c
|
||||
|
||||
|
||||
@ -1,134 +0,0 @@
|
||||
Samba Architecture
|
||||
------------------
|
||||
|
||||
First preliminary version Dan Shearer Nov 97
|
||||
Quickly scrabbled together from odd bits of mail and memory. Please update.
|
||||
|
||||
This document gives a general overview of how Samba works
|
||||
internally. The Samba Team has tried to come up with a model which is
|
||||
the best possible compromise between elegance, portability, security
|
||||
and the constraints imposed by the very messy SMB and CIFS
|
||||
protocol.
|
||||
|
||||
It also tries to answer some of the frequently asked questions such as:
|
||||
|
||||
* Is Samba secure when running on Unix? The xyz platform?
|
||||
What about the root priveliges issue?
|
||||
|
||||
* Pros and cons of multithreading in various parts of Samba
|
||||
|
||||
* Why not have a separate process for name resolution, WINS,
|
||||
and browsing?
|
||||
|
||||
|
||||
Multithreading and Samba
|
||||
------------------------
|
||||
|
||||
People sometimes tout threads as a uniformly good thing. They are very
|
||||
nice in their place but are quite inappropriate for smbd. nmbd is
|
||||
another matter, and multi-threading it would be very nice.
|
||||
|
||||
The short version is that smbd is not multithreaded, and alternative
|
||||
servers that take this approach under Unix (such as Syntax, at the
|
||||
time of writing) suffer tremendous performance penalties and are less
|
||||
robust. nmbd is not threaded either, but this is because it is not
|
||||
possible to do it while keeping code consistent and portable across 35
|
||||
or more platforms. (This drawback also applies to threading smbd.)
|
||||
|
||||
The longer versions is that there are very good reasons for not making
|
||||
smbd multi-threaded. Multi-threading would actually make Samba much
|
||||
slower, less scalable, less portable and much less robust. The fact
|
||||
that we use a separate process for each connection is one of Samba's
|
||||
biggest advantages.
|
||||
|
||||
Threading smbd
|
||||
--------------
|
||||
|
||||
A few problems that would arise from a threaded smbd are:
|
||||
|
||||
0) It's not only to create threads instead of processes, but you
|
||||
must care about all variables if they have to be thread specific
|
||||
(currently they would be global).
|
||||
|
||||
1) if one thread dies (eg. a seg fault) then all threads die. We can
|
||||
immediately throw robustness out the window.
|
||||
|
||||
2) many of the system calls we make are blocking. Non-blocking
|
||||
equivalents of many calls are either not available or are awkward (and
|
||||
slow) to use. So while we block in one thread all clients are
|
||||
waiting. Imagine if one share is a slow NFS filesystem and the others
|
||||
are fast, we will end up slowing all clients to the speed of NFS.
|
||||
|
||||
3) you can't run as a different uid in different threads. This means
|
||||
we would have to switch uid/gid on _every_ SMB packet. It would be
|
||||
horrendously slow.
|
||||
|
||||
4) the per process file descriptor limit would mean that we could only
|
||||
support a limited number of clients.
|
||||
|
||||
5) we couldn't use the system locking calls as the locking context of
|
||||
fcntl() is a process, not a thread.
|
||||
|
||||
Threading nmbd
|
||||
--------------
|
||||
|
||||
This would be ideal, but gets sunk by portability requirements.
|
||||
|
||||
Andrew tried to write a test threads library for nmbd that used only
|
||||
ansi-C constructs (using setjmp and longjmp). Unfortunately some OSes
|
||||
defeat this by restricting longjmp to calling addresses that are
|
||||
shallower than the current address on the stack (apparently AIX does
|
||||
this). This makes a truly portable threads library impossible. So to
|
||||
support all our current platforms we would have to code nmbd both with
|
||||
and without threads, and as the real aim of threads is to make the
|
||||
code clearer we would not have gained anything. (it is a myth that
|
||||
threads make things faster. threading is like recursion, it can make
|
||||
things clear but the same thing can always be done faster by some
|
||||
other method)
|
||||
|
||||
Chris tried to spec out a general design that would abstract threading
|
||||
vs separate processes (vs other methods?) and make them accessible
|
||||
through some general API. This doesn't work because of the data
|
||||
sharing requirements of the protocol (packets in the future depending
|
||||
on packets now, etc.) At least, the code would work but would be very
|
||||
clumsy, and besides the fork() type model would never work on Unix. (Is there an OS that it would work on, for nmbd?)
|
||||
|
||||
A fork() is cheap, but not nearly cheap enough to do on every UDP
|
||||
packet that arrives. Having a pool of processes is possible but is
|
||||
nasty to program cleanly due to the enormous amount of shared data (in
|
||||
complex structures) between the processes. We can't rely on each
|
||||
platform having a shared memory system.
|
||||
|
||||
nbmd Design
|
||||
-----------
|
||||
|
||||
Originally Andrew used recursion to simulate a multi-threaded
|
||||
environment, which use the stack enormously and made for really
|
||||
confusing debugging sessions. Luke Leighton rewrote it to use a
|
||||
queuing system that keeps state information on each packet. The
|
||||
first version used a single structure which was used by all the
|
||||
pending states. As the initialisation of this structure was
|
||||
done by adding arguments, as the functionality developed, it got
|
||||
pretty messy. So, it was replaced with a higher-order function
|
||||
and a pointer to a user-defined memory block. This suddenly
|
||||
made things much simpler: large numbers of functions could be
|
||||
made static, and modularised. This is the same principle as used
|
||||
in NT's kernel, and achieves the same effect as threads, but in
|
||||
a single process.
|
||||
|
||||
Then Jeremy rewrote nmbd. The packet data in nmbd isn't what's on the
|
||||
wire. It's a nice format that is very amenable to processing but still
|
||||
keeps the idea of a distinct packet. See "struct packet_struct" in
|
||||
nameserv.h. It has all the detail but none of the on-the-wire
|
||||
mess. This makes it ideal for using in disk or memory-based databases
|
||||
for browsing and WINS support.
|
||||
|
||||
nmbd now consists of a series of modules. It...
|
||||
|
||||
|
||||
Samba Design and Security
|
||||
-------------------------
|
||||
|
||||
Why Isn't nmbd Multiple Daemons?
|
||||
--------------------------------
|
||||
|
||||
@ -566,7 +566,23 @@ AC_ARG_WITH(codepagedir,
|
||||
esac])
|
||||
|
||||
AC_MSG_CHECKING([configure summary])
|
||||
AC_TRY_RUN([#include "${srcdir-.}/tests/summary.c"],
|
||||
AC_TRY_RUN([
|
||||
#include <stdio.h>
|
||||
|
||||
main()
|
||||
{
|
||||
#if !(defined(HAVE_NETMASK_IFCONF) || defined(HAVE_NETMASK_IFREQ) || defined(HAVE_NETMASK_AIX))
|
||||
printf("WARNING: No automated netmask determination - use an interfaces line\n");
|
||||
#endif
|
||||
|
||||
#if !((defined(HAVE_RANDOM) || defined(HAVE_RAND)) && (defined(HAVE_SRANDOM) || defined(HAVE_SRAND)))
|
||||
printf("ERROR: No random or srandom routine!\n");
|
||||
exit(1);
|
||||
#endif
|
||||
|
||||
exit(0);
|
||||
}
|
||||
],
|
||||
AC_MSG_RESULT(OK);,
|
||||
AC_MSG_RESULT(failure)
|
||||
AC_MSG_ERROR([Aborting config]),:)
|
||||
|
||||
@ -1,56 +0,0 @@
|
||||
/*
|
||||
Unix SMB/Netbios implementation.
|
||||
Version 1.9.
|
||||
some simple double linked list macros
|
||||
Copyright (C) Andrew Tridgell 1998
|
||||
|
||||
This program is free software; you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
*/
|
||||
|
||||
/* To use these macros you must have a structure containing a next and
|
||||
prev pointer */
|
||||
|
||||
|
||||
/* hook into the front of the list */
|
||||
#define DLIST_ADD(list, p) \
|
||||
{ \
|
||||
if (!(list)) { \
|
||||
(list) = (p); \
|
||||
(p)->next = (p)->prev = NULL; \
|
||||
} else { \
|
||||
(list)->prev = (p); \
|
||||
(p)->next = (list); \
|
||||
(p)->prev = NULL; \
|
||||
(list) = (p); \
|
||||
}\
|
||||
}
|
||||
|
||||
|
||||
/* remove an element from a list */
|
||||
#define DLIST_REMOVE(list, p) \
|
||||
{ \
|
||||
if ((p) == (list)) { \
|
||||
(list) = (p)->next; \
|
||||
if (list) (list)->prev = NULL; \
|
||||
} else { \
|
||||
(p)->prev->next = (p)->next; \
|
||||
if ((p)->next) (p)->next->prev = (p)->prev; \
|
||||
} \
|
||||
}
|
||||
|
||||
/* promote an element to the top of the list */
|
||||
#define DLIST_PROMOTE(list, p) \
|
||||
DLIST_REMOVE(list, p) \
|
||||
DLIST_ADD(list, p)
|
||||
@ -519,9 +519,6 @@ extern int errno;
|
||||
#endif
|
||||
|
||||
|
||||
/* Lists, trees, caching, datbase... */
|
||||
#include "dlinklist.h"
|
||||
|
||||
#include "version.h"
|
||||
#include "smb.h"
|
||||
#include "nameserv.h"
|
||||
|
||||
@ -366,9 +366,6 @@ BOOL cli_dskattr(struct cli_state *cli, int *bsize, int *total, int *avail);
|
||||
|
||||
/* The following definitions come from libsmb/namequery.c */
|
||||
|
||||
BOOL name_status(int fd,char *name,int name_type,BOOL recurse,
|
||||
struct in_addr to_ip,char *master,char *rname,
|
||||
void (*fn)(struct packet_struct *));
|
||||
struct in_addr *name_query(int fd,const char *name,int name_type, BOOL bcast,BOOL recurse,
|
||||
struct in_addr to_ip, int *count, void (*fn)(struct packet_struct *));
|
||||
FILE *startlmhosts(char *fname);
|
||||
|
||||
@ -1,10 +0,0 @@
|
||||
This directory contains autoconf test programs that are too large to
|
||||
comfortably fit in configure.in.
|
||||
|
||||
These programs should test one feature of the OS and exit(0) if it
|
||||
works or exit(1) if it doesn't work (do _not_ use return)
|
||||
|
||||
The programs should be kept simple and to the point. Beautiful/fast
|
||||
code is not necessary
|
||||
|
||||
|
||||
@ -1,15 +0,0 @@
|
||||
#include <stdio.h>
|
||||
|
||||
main()
|
||||
{
|
||||
#if !(defined(HAVE_NETMASK_IFCONF) || defined(HAVE_NETMASK_IFREQ) || defined(HAVE_NETMASK_AIX))
|
||||
printf("WARNING: No automated netmask determination - use an interfaces line\n");
|
||||
#endif
|
||||
|
||||
#if !((defined(HAVE_RANDOM) || defined(HAVE_RAND)) && (defined(HAVE_SRANDOM) || defined(HAVE_SRAND)))
|
||||
printf("ERROR: No random or srandom routine!\n");
|
||||
exit(1);
|
||||
#endif
|
||||
|
||||
exit(0);
|
||||
}
|
||||
Загрузка…
x
Ссылка в новой задаче
Block a user