Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Message-ID: <01cd01c1a6dd$4619e550$0200a8c0@lifelesswks> From: "Robert Collins" To: Subject: Daemon reviewer Date: Sun, 27 Jan 2002 13:49:43 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 27 Jan 2002 02:49:39.0152 (UTC) FILETIME=[43615500:01C1A6DD] Gary, will you have to time make some sort of comment on the code/design quality in the next (say) fortnight? If not, please say so. Likewise, Egor, Corinna, you both showed interest in having a daemon for various tasks, and we have a potential daemon, all it needs is peer review. If you don't have the time to review the results of ourgroup discussion last year, please say so. Chris, please make (yet another :}) clear statement about what output you want from a reviewer, what credentials you need them to have (ie will any of Gary/Egor/Corinna do?) and please think about what the way forward will when you recieve that input. The diff for the daemon is 130K. Thats not a lot of code (under 4400 lines, including the diff headers and the not-to-be-included shared memory and IPC code). It's got unix pipe (win9x) and Named Pipe (winNT) support. It's got secured tty handle passing. It's got a object based request marshaling approach, allowing for easy extension. It's got partial support for process management (ie callback an object when process foo exits). (Not needed for the initial merge - part of the shm code). It's multi-threaded (with blocking IO to be safe on win9x). I've been using it exclusively for MONTHS with no problems. It's not perfect (what is), but it should not have any negative impact on cygwin or cygwin stability when. It shouldn't affect Redhat clients, or net users, unless they choose to run it. It doesn't disable anything core, only enables better security, (potentially performance) and functionality when it is running. And this is the kicker: I'm stopping maintenance the cvs branch unless one of two things happen: * I get a clear indication of what needs to be changed for inclusion. * I get the go-ahead to include the non-shm aspects of the code. I can't afford the time investment maintaining a dead branch, and unless one of the two above things happen, I've got to consider it dead, with no community support. This isn't an ultimatum or anything silly like that, just a statement of fact. The branch can stay there as long as needed, but I'll not be changing it, unless I need a specific feature from HEAD. Rob