[SCM] Samba Shared Repository - branch v4-0-test updated - release-4-0-0alpha2-700-gea718a0

Jelmer Vernooij jelmer at samba.org
Sun Feb 10 21:31:56 GMT 2008


The branch, v4-0-test has been updated
       via  ea718a0c0b1efd73020da6d5a362b371afd8e371 (commit)
       via  20c15884c84151d01f50cdba571b3ba4be1a9fd8 (commit)
      from  80dbf04266d15833f7eb18704cfece1f95965e83 (commit)

http://gitweb.samba.org/?p=samba.git;a=shortlog;h=v4-0-test


- Log -----------------------------------------------------------------
commit ea718a0c0b1efd73020da6d5a362b371afd8e371
Author: Jelmer Vernooij <jelmer at samba.org>
Date:   Sun Feb 10 22:24:09 2008 +0100

    Make formatting a bit more ReST-valid.

commit 20c15884c84151d01f50cdba571b3ba4be1a9fd8
Author: Jelmer Vernooij <jelmer at samba.org>
Date:   Sun Feb 10 22:14:08 2008 +0100

    Change README to be ReST-compatible.

-----------------------------------------------------------------------

Summary of changes:
 README         |   37 ++++++++++++++++++---------------
 TODO           |    6 -----
 prog_guide.txt |   60 ++++++++++++++++++++++++++++----------------------------
 3 files changed, 50 insertions(+), 53 deletions(-)


Changeset truncated at 500 lines:

diff --git a/README b/README
index c1034b3..5501998 100644
--- a/README
+++ b/README
@@ -1,3 +1,6 @@
+Readme for Samba 4
+==================
+
 Samba 4 is the ambitious next version of the Samba suite that is being
 developed in parallel to the stable 3.0 series. The main emphasis in
 this branch is support for the Active Directory logon protocols used
@@ -15,8 +18,8 @@ Technology Preview (TP), aimed at allowing you, our users, managers and
 developers to see how we have progressed, and to invite your feedback and
 support.
 
-WARNINGS
-========
+Warnings
+--------
 
 Samba4 is currently at alpha stage.  That is more a reference to
 Samba4's lack of the features we expect you will need than a statement
@@ -58,8 +61,8 @@ logged in user, much as Samba3 does.
 As such, we must strongly recommend against using Samba4 in a
 production environment at this stage.
 
-NEW FEATURES
-============
+New Features
+------------
 
 Samba4 supports the server-side of the Active Directory logon environment
 used by Windows 2000 and later, so we can do full domain join
@@ -93,20 +96,20 @@ working on modules to map between AD-like behaviours and this back-end.
 We are aiming for Samba 4 to be powerful front-end to large
 directories.
 
-CHANGES
-=======
+Changes
+-------
 
 Those familiar with Samba 3 can find a list of user-visible changes
 since that release series in the NEWS file.
 
- - An optional password is no longer supported as the second argument to
-   smbclient.
+- An optional password is no longer supported as the second argument to
+  smbclient.
 
- - The default location of smb.conf in non-FHS builds has changed from the
-   PREFIX/lib directory to the PREFIX/etc directory.
+- The default location of smb.conf in non-FHS builds has changed from the
+  PREFIX/lib directory to the PREFIX/etc directory.
 
-KNOWN ISSUES
-============
+Known issues
+------------
 
 - Standalone server and domain member roles are not currently
   supported.  While we have much of the infrastructure required, we
@@ -117,14 +120,15 @@ KNOWN ISSUES
 - SWAT can be painful with <TAB> and forms.  Just use the mouse, as
   the JavaScript layer doing this will change.
 
-RUNNING Samba4
-==============
+Running Samba4
+--------------
 
 A short guide to setting up Samba 4 can be found in the howto.txt file
 in root of the tarball.
 
-DEVELOPMENT and FEEDBACK
-========================
+Development and feedback
+------------------------
+
 Bugs can be filed at https://bugzilla.samba.org/. Please
 look at the STATUS file before filing a bug to see if a particular
 is supposed to work yet.
@@ -134,4 +138,3 @@ the #samba-technical IRC channel (on irc.freenode.net) and
 the samba-technical mailing list (see http://lists.samba.org/ for
 details).
 
-
diff --git a/TODO b/TODO
index 65dca88..14df8a5 100644
--- a/TODO
+++ b/TODO
@@ -3,15 +3,9 @@ source/lib/registry/TODO
 source/lib/tdr/TODO
 source/pidl/TODO
 
-upgrade process (from Samba3):
- - Rename upgrade to upgrade3 (to avoid confusion with upgrades 
-   from earlier Samba4 releases in the future)
- - Add support for reading WINS TDB files as well as WINS dat files.
-
 - seperate adminlog mechanism (as opposed to the current DEBUG log,
   which is not really aimed at administrators but more at developers)
   Perhaps similar to eventlog so we can also use eventlog to retrieve the data?
-- improve handling of test results in testsuite
 
 - testsuite for the 'net' tool
 
diff --git a/prog_guide.txt b/prog_guide.txt
index 3814a11..bba58b3 100644
--- a/prog_guide.txt
+++ b/prog_guide.txt
@@ -58,11 +58,11 @@ Static and Global Data
 
 The basic rule is "avoid static and global data like the plague". What
 do I mean by static data? The way to tell if you have static data in a
-file is to use the "size" utility in Linux. For example if we run:
+file is to use the "size" utility in Linux. For example if we run::
 
   size libcli/raw/*.o
 
-in Samba4 then you get the following:
+in Samba4 then you get the following::
 
    text    data     bss     dec     hex filename
    2015       0       0    2015     7df libcli/raw/clikrb5.o
@@ -91,7 +91,7 @@ notice that the "data" and "bss" columns are all zero? That is
 good. If there are any non-zero values in data or bss then that
 indicates static data and is bad (as a rule of thumb).
 
-Lets compare that result to the equivalent in Samba3:
+Lets compare that result to the equivalent in Samba3::
 
    text    data     bss     dec     hex filename
    3978       0       0    3978     f8a libsmb/asn1.o
@@ -142,11 +142,11 @@ notice all of the non-zero data and bss elements? Every bit of that
 data is a bug waiting to happen.
 
 Static data is evil as it has the following consequences:
- - it makes code much less likely to be thread-safe
- - it makes code much less likely to be recursion-safe
- - it leads to subtle side effects when the same code is called from
-   multiple places
- - doesn't play well with shared libraries or plugins
+- it makes code much less likely to be thread-safe
+- it makes code much less likely to be recursion-safe
+- it leads to subtle side effects when the same code is called from
+  multiple places
+- doesn't play well with shared libraries or plugins
 
 Static data is particularly evil in library code (such as our internal
 smb and rpc libraries). If you can get rid of all static data in
@@ -237,23 +237,23 @@ In the Samba3 msrpc code we used explicit parse structures for all
 msrpc functions. The problem is that we didn't just put all of the
 real variables in these structures, we also put in all the artifacts
 as well. A good example is the security descriptor strucrure that
-looks like this in Samba3:
+looks like this in Samba3::
 
-typedef struct security_descriptor_info
-{
-	uint16 revision; 
-	uint16 type;    
+	typedef struct security_descriptor_info
+	{
+		uint16 revision; 
+		uint16 type;    
 
-	uint32 off_owner_sid;
-	uint32 off_grp_sid;
-	uint32 off_sacl;
-	uint32 off_dacl;
+		uint32 off_owner_sid;
+		uint32 off_grp_sid;
+		uint32 off_sacl;
+		uint32 off_dacl;
 
-	SEC_ACL *dacl;
-	SEC_ACL *sacl;
-	DOM_SID *owner_sid; 
-	DOM_SID *grp_sid;
-} SEC_DESC;
+		SEC_ACL *dacl;
+		SEC_ACL *sacl;
+		DOM_SID *owner_sid; 
+		DOM_SID *grp_sid;
+	} SEC_DESC;
 
 The problem with this structure is all the off_* variables. Those are
 not part of the interface, and do not appear in any real descriptions
@@ -301,11 +301,11 @@ just about everywhere.
 
 The first aspect of the async design to look at is the SMB client
 library. Lets take a look at the following three functions in
-libcli/raw/rawfile.c:
+libcli/raw/rawfile.c::
 
-struct cli_request *smb_raw_seek_send(struct cli_tree *tree, struct smb_seek *parms);
-NTSTATUS smb_raw_seek_recv(struct cli_request *req, struct smb_seek *parms);
-NTSTATUS smb_raw_seek(struct cli_tree *tree, struct smb_seek *parms);
+	struct cli_request *smb_raw_seek_send(struct cli_tree *tree, struct smb_seek *parms);
+	NTSTATUS smb_raw_seek_recv(struct cli_request *req, struct smb_seek *parms);
+	NTSTATUS smb_raw_seek(struct cli_tree *tree, struct smb_seek *parms);
 
 Go and read them now then come back.
 
@@ -327,7 +327,7 @@ one called smb_raw_XXXX(). That just calls the first two in order, and
 blocks waiting for the reply. 
 
 But what if you want to be called when the reply comes in? Yes, thats
-possible. You can do things like this:
+possible. You can do things like this::
 
     struct cli_request *req;
 
@@ -374,7 +374,7 @@ to just like in Samba3, but it also has the option of answering the
 request asynchronously. The only backend that currently does this is
 the CIFS backend, but I hope the other backends will soon do this to.
 
-To make this work you need to do things like this in the backend:
+To make this work you need to do things like this in the backend::
 
   req->control_flags |= REQ_CONTROL_ASYNC;
 
@@ -450,7 +450,7 @@ and read it. Yes, that means you!).
 Notice the union? That's how Samba4 allows a single NTVFS backend
 interface to handle the several different ways of doing a write
 operation in the SMB protocol. Now lets look at one section of that
-union:
+union::
 
 	/* SMBwriteX interface */
 	struct {
@@ -473,7 +473,7 @@ union:
 see the "in" and "out" sections? The "in" section is for parameters
 that the SMB client sends on the wire as part of the request. The smbd
 front end parse code parses the wire request and fills in all those
-parameters. It then calls the NTVFS interface which looks like this:
+parameters. It then calls the NTVFS interface which looks like this::
 
   NTSTATUS (*write)(struct request_context *req, union smb_write *io);
 


-- 
Samba Shared Repository


More information about the samba-cvs mailing list