From owner-freebsd-arch@FreeBSD.ORG Sun Apr 15 09:31:51 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 369CA16A401 for ; Sun, 15 Apr 2007 09:31:51 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from blue.servers.aueb.gr (blue.servers.aueb.gr [195.251.255.132]) by mx1.freebsd.org (Postfix) with ESMTP id B6D6D13C44B for ; Sun, 15 Apr 2007 09:31:50 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from [127.0.0.1] ([::ffff:195.251.249.147]) by blue.servers.aueb.gr with esmtp; Sun, 15 Apr 2007 12:31:45 +0300 id 000D52FA.4621F101.00001A82 Message-ID: <4621E826.6050306@aueb.gr> Date: Sun, 15 Apr 2007 11:53:58 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Robert Watson References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> In-Reply-To: <20070414170218.M76326@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, re@freebsd.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 09:31:51 -0000 Robert Watson wrote: > > On Mon, 9 Apr 2007, Diomidis Spinellis wrote: > >> I'd like your permission to perform a change during the slush period. >> >> Following some gentle prodding by bde, I'm working on an overhaul of >> the accounting system. The reason for the change is that time values >> with AHZ == 64 (1/64 second) are very often zero on modern machines. >> The change involves storing acct(5) time values as proper IEEE-487 >> floats with AHZ being 1000000 (i.e storing \mu s). For the change >> I'll touch the following files/directories: >> >> sys/sys/acct.h >> sys/kern/kern_acct.c >> usr.sbin/sa >> usr.bin/lastcomm >> share/man/man5/acct.5 >> UPDATING >> >> The change will render old daily accounting files incompatible with >> the new commands and formats. Because the summary databases don't >> store any version information, the old versions of these will also >> become unusable. Therefore users will need to clear >> /var/account{acct*,savacct,usracct}. Apparently, this problem has >> occurred multiple times in the past, when we changed the size of >> elements like uid_t and dev_t. > > What do you think of the idea of changing the file format a little to > include a short file header at the front, and that the first field of > that head is zero-filled u_int32_t, and the second a version number? > Right now, the first field of the acct structure is the name of the > command, which will always be a non-nul string, so always have a first > character non-nul. If we see non-nul data in the file header's first > field, we use the old structure layout, and otherwise we check the > version number and use the new layout? This would provide backwards > compatibility for reading old accounting data, which I would think would > generally be desirable, and allow us to explicitly version the file in > the future. There are three types of accounting files: acct(5), which contains records written by the kernel, and two others containing sa(8) aggregated results of acct per user and per command. I'd prefer to keep acct(5) free of version data. This 1) simplifies the kernel, which would otherwise have to write version data each time the file is turned over, 2) is consistent with current practice for storing such files, and 3) simplifies the processing programs, which can process data at arbritrary locations in the file. (lastcomm reads records backwards, and recently I updated it to also work on the output of tail -f). Typically, these files are aggregated and turned over daily; IMO doing this also over an OS upgrade isn't a big deal. The aggregated files are different. They are dbm-based, and their structure is opaque. I could therefore easily add a special "file version" record to them. My concern is how to handle multiple file versions over a long time period. Hard-coding legacy file formats in the code is inelegant. I'd prefer to add a text-based import/export capability, so that administrators can migrate data by exporting it before an OS upgrade and importing it afterwords. Even that could be an overkill. Based on the problems Bruce and I have seen in the accounting system, my impression is that not many people use it nowadays. Once/if we get dtrace in FreeBSD, I'd prever to scrap t existing accounting infrastructure and re-implement it on top of that. Diomidis - http://www.spinellis.gr From owner-freebsd-arch@FreeBSD.ORG Sun Apr 15 09:53:33 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60C4B16A400; Sun, 15 Apr 2007 09:53:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1762E13C459; Sun, 15 Apr 2007 09:53:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 10B7647FEF; Sun, 15 Apr 2007 05:53:32 -0400 (EDT) Date: Sun, 15 Apr 2007 10:53:32 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Diomidis Spinellis In-Reply-To: <4621E826.6050306@aueb.gr> Message-ID: <20070415105157.J84174@fledge.watson.org> References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, re@freebsd.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 09:53:33 -0000 On Sun, 15 Apr 2007, Diomidis Spinellis wrote: >> What do you think of the idea of changing the file format a little to >> include a short file header at the front, and that the first field of that >> head is zero-filled u_int32_t, and the second a version number? Right now, >> the first field of the acct structure is the name of the command, which >> will always be a non-nul string, so always have a first character non-nul. >> If we see non-nul data in the file header's first field, we use the old >> structure layout, and otherwise we check the version number and use the new >> layout? This would provide backwards compatibility for reading old >> accounting data, which I would think would generally be desirable, and >> allow us to explicitly version the file in the future. > > There are three types of accounting files: acct(5), which contains records > written by the kernel, and two others containing sa(8) aggregated results of > acct per user and per command. I'd prefer to keep acct(5) free of version > data. This 1) simplifies the kernel, which would otherwise have to write > version data each time the file is turned over, 2) is consistent with > current practice for storing such files, and 3) simplifies the processing > programs, which can process data at arbritrary locations in the file. > (lastcomm reads records backwards, and recently I updated it to also work on > the output of tail -f). Typically, these files are aggregated and turned > over daily; IMO doing this also over an OS upgrade isn't a big deal. The sites I know of that use accounting don't care about CPU use in the sa(8) sense at all. They care about tracking commands run. While acct(5) doesn't do this extraordinarily well, it does it well enough to allow basic command execution logging and analysis. Hence the desire to be able to continue readding preserved acct(5) data files in the future. Robert N M Watson Computer Laboratory University of Cambridge > > The aggregated files are different. They are dbm-based, and their structure > is opaque. I could therefore easily add a special "file version" record to > them. My concern is how to handle multiple file versions over a long time > period. Hard-coding legacy file formats in the code is inelegant. I'd > prefer to add a text-based import/export capability, so that administrators > can migrate data by exporting it before an OS upgrade and importing it > afterwords. > > Even that could be an overkill. Based on the problems Bruce and I have seen > in the accounting system, my impression is that not many people use it > nowadays. Once/if we get dtrace in FreeBSD, I'd prever to scrap t existing > accounting infrastructure and re-implement it on top of that. > > Diomidis - http://www.spinellis.gr > > From owner-freebsd-arch@FreeBSD.ORG Mon Apr 16 07:00:52 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C313916A40E for ; Mon, 16 Apr 2007 07:00:52 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 3F0B713C4AD for ; Mon, 16 Apr 2007 07:00:51 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l3G6nnQx015227; Mon, 16 Apr 2007 09:49:50 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3G6nnER001038; Mon, 16 Apr 2007 09:49:49 +0300 Received: from [192.168.136.22] (ppp121-97.adsl.forthnet.gr [193.92.228.97]) by MX-IN-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3G6nfHb024207; Mon, 16 Apr 2007 09:49:41 +0300 Authentication-Results: MX-IN-02.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <46231C64.9010707@aueb.gr> Date: Mon, 16 Apr 2007 09:49:08 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Robert Watson References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> In-Reply-To: <20070415105157.J84174@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 07:00:52 -0000 Robert Watson wrote: >>> What do you think of the idea of changing the file format a little to >>> include a short file header at the front, and that the first field of >>> that head is zero-filled u_int32_t, and the second a version number? >>> Right now, the first field of the acct structure is the name of the >>> command, which will always be a non-nul string, so always have a >>> first character non-nul. If we see non-nul data in the file header's >>> first field, we use the old structure layout, and otherwise we check >>> the version number and use the new layout? This would provide >>> backwards compatibility for reading old accounting data, which I >>> would think would generally be desirable, and allow us to explicitly >>> version the file in the future. >> > > The sites I know of that use accounting don't care about CPU use in the > sa(8) sense at all. They care about tracking commands run. While > acct(5) doesn't do this extraordinarily well, it does it well enough to > allow basic command execution logging and analysis. Hence the desire to > be able to continue readding preserved acct(5) data files in the future. I see three options for satisfying this requirement. One is to move the existing acct.h into usr.bin/lastcomm, and add to lastcomm(1) and option to read legacy files. I don't like this approach, because it doesn't include sa(8) in the picture, and, more importantly, it doesn't scale well for future changes. Every time we change the type of a field of acct.h (for example widening ac_gid) we will have to add architecture-specific code in the legacy file reading module. A variation of the above approach would be to create a library for reading legacy accounting data formats. I think this is an overkill, given that the two users are sa(8) and lastcomm(1), and of the two lastcomm appears to be really needed. The approach I favor is to add to lastcomm an option to dump an accounting file in text format, and a second option to read text accounting data from stdin and write it out in the current accounting file format. Users can then either store accounting data in (compressed) text files, or pipe them through a pipeline that will transform the legacy format into the current one. (In the latter case they will need to keep through an upgrade a lastcomm(1) binary compiled to read the legacy format - I can provide the appropriate cvs incantation in UPDATING). This approach also simplifies the writing of test cases. Diomidis - http://www.spinellis.gr From owner-freebsd-arch@FreeBSD.ORG Mon Apr 16 13:31:27 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8329216A407 for ; Mon, 16 Apr 2007 13:31:27 +0000 (UTC) (envelope-from tcheek@pixelfish.com) Received: from mail01.vmatrixmail.com (mail01.vmatrixmail.com [216.219.244.230]) by mx1.freebsd.org (Postfix) with ESMTP id 3876713C468 for ; Mon, 16 Apr 2007 13:31:27 +0000 (UTC) (envelope-from tcheek@pixelfish.com) Received: (vmatrix@mail01.vmatrixmail.com) by vmatrixmail.com id S6077888AbXDPN22 for ; Mon, 16 Apr 2007 06:28:28 -0700 To: freebsd-arch@freebsd.org MIME-Version: 1.0 X-Mailer: Rich Media Mail V4. Vmatrix, (C) 2003 From: "Tammie Cheek" Sender: "Tammie Cheek" Message-Id: Date: Mon, 16 Apr 2007 06:28:28 -0700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Technology Industry Moves To Video X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcheek@pixelfish.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 13:31:27 -0000 Greetings!

Are you happy with your results from the Southern California Linux Expo 2007? Did you have what it takes to make the difference between creating excitement and blending in with the competition, between lots of hot leads and a few hard sells ... between success and failure?

Did you have video?

Why video? Video vividly demonstrates the features and benefits of your products. Video captures the praises of your most enthusiastic customers. Video instills interest, reaction and trust. Video sells.

In just 45 days, PixelFish creates marketing videos that become an integral part of your marketing and sales efforts when it streams from your Web site, launches from multimedia email newsletters, plays from CD video brochures and loops from a DVD at your tradeshow booth.

We are PixelFish. We deliver “The Evolution of Video”. And we guarantee results. Click on the videos to the right to see samples of our work.

Contact us today for a free evaluation of your video marketing needs.


Tammie Cheek
PixelFish, Inc.
800.503.3020 x7110
tcheek@pixelfish.com
http://www.pixelfish.com
Interim Video
Empire Stat Group Video
Columbia Healthcare Analytics Video
------------------------------------------------ Unsubscribe to safely remove yourself from this email list, please send email to info@pixelfish.com. Powered by Pixelfish http://www.pixelfish.com From owner-freebsd-arch@FreeBSD.ORG Tue Apr 17 17:41:29 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA5F116A404; Tue, 17 Apr 2007 17:41:29 +0000 (UTC) (envelope-from thIOretic@yandex.ru) Received: from mfront8.mail.yandex.net (mfront8.mail.yandex.net [213.180.223.98]) by mx1.freebsd.org (Postfix) with ESMTP id A6D5C13C4AD; Tue, 17 Apr 2007 17:41:29 +0000 (UTC) (envelope-from thIOretic@yandex.ru) Received: from YAMAIL (mfront8.yandex.ru) by mail.yandex.ru id ; Tue, 17 Apr 2007 21:21:59 +0400 Received: from [80.92.248.155] ([80.92.248.155]) by mail.yandex.ru with HTTP; Tue, 17 Apr 2007 21:21:59 +0400 (MSD) Date: Tue, 17 Apr 2007 21:21:59 +0400 (MSD) From: "thIOretic" Sender: thIOretic@yandex.ru Message-Id: <46250237.000008.20157@mfront8.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: thIOretic@yandex.ru To: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org X-MsgDayCount: 2 X-BornDate: 1105563600 X-Source-Ip: 80.92.248.155 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: thioretic@FreeBSD.org, nsouch@free.fr, philip@FreeBSD.org Subject: GSoC project community intro and sync X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thIOretic@yandex.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 17:41:30 -0000 Hi, hackers. I'm working on 'Generic input device layer' GSoC2007 project (http://wiki.freebsd.org/SummerOfCode2007). This mail is actually to introduce my ideas and to synchronize it with current community efforts. --Intro-- The project addresses input devices handling and multiplexing. The proposal with raw design is located at http://wiki.freebsd.org/GenericInputDeviceLayer. It also includes current state overview. In brief, the proposal suggests to implement input handling via usermode drivers stacks. Usermode stage is handled by usermode drivers framework. The device class specific data is specified by 'exporters'. --Sync-- I would like to get info from everyone, who may take similar efforts in FreeBSD input handling. I'm aware of * newpsm framework * KGI/KII * vtc(4) was mentioned, but its code seems to do nothing from my project thesis perspective. Or I've missed something? Maybe we will find some optimal design that will unify our efforts. --Generic input handling ... even more generic layer-- I will appreciate any ideas from people, who may find the usermode drivers approach useful for their projects. Any useful discussion may result in some more generic design, that will fit more needs. E.g. one of generalization ways is to allow exporters to specify drivers interface. P.S. please 'reply all', so that all CC'd people receive their copy. Thanks, - Maxim From owner-freebsd-arch@FreeBSD.ORG Tue Apr 17 19:36:07 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 182E516A409; Tue, 17 Apr 2007 19:36:07 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.171]) by mx1.freebsd.org (Postfix) with ESMTP id EB39213C45D; Tue, 17 Apr 2007 19:36:06 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/smtpout01/MantshX 4.0) with ESMTP id l3HJO32V007031; Tue, 17 Apr 2007 12:24:03 -0700 (PDT) Received: from [172.24.104.161] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l3HJO0cH027667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2007 12:24:01 -0700 (PDT) In-Reply-To: <46250237.000008.20157@mfront8.yandex.ru> References: <46250237.000008.20157@mfront8.yandex.ru> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 17 Apr 2007 12:23:00 -0700 To: thIOretic@yandex.ru X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-hackers@FreeBSD.org, philip@FreeBSD.org, thioretic@FreeBSD.org, nsouch@free.fr, freebsd-arch@FreeBSD.org Subject: Re: GSoC project community intro and sync X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 19:36:07 -0000 On Apr 17, 2007, at 10:21 AM, thIOretic wrote: > I would like to get info from everyone, who may take similar > efforts in FreeBSD input handling. I'm aware of > * newpsm framework > * KGI/KII > * vtc(4) was mentioned, but its code seems to do nothing from my > project thesis perspective. Or I've missed something? As for vtc(4): I've not been working on input devices because of the lack of a generic layer. Note that vtc(4) deals with the low-level console as much as it deals with user-visible terminals, so from that point of view, a user space stack will not address the need for having console input when there's no (functional) user space -- this includes early boot, the kernel debugger and single-user mode. I therefore doubt that it will sufficiently (or at all) solve problems we already have. Also, while multiplexing is an important feature I think that de- multiplexing is important too. With USB and multi-head or multiple graphics cards it's conceptually easy to turn a PC into a multi- user workstation, having multiple independent terminals. This implies that input devices need to be tied to output devices, which together form one or more terminals. In short: We do need a generic input framework, but I think we need it in the kernel, not in user space. I also think that a generic input layer should be capable of handling both focussed and non- focussed input devices to lay the foundation for configurations that do not include keyboards. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Tue Apr 17 22:43:25 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C074D16A401; Tue, 17 Apr 2007 22:43:25 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174]) by mx1.freebsd.org (Postfix) with ESMTP id A0AE113C4CA; Tue, 17 Apr 2007 22:43:25 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/smtpout04/MantshX 4.0) with ESMTP id l3HMhNVl028678; Tue, 17 Apr 2007 15:43:23 -0700 (PDT) Received: from [172.24.104.161] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l3HMhHA3003388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2007 15:43:18 -0700 (PDT) In-Reply-To: References: <46250237.000008.20157@mfront8.yandex.ru> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 17 Apr 2007 15:42:19 -0700 To: Maxim Zhuravlev X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-hackers@FreeBSD.org, thIOretic@yandex.ru, philip@FreeBSD.org, nsouch@free.fr, freebsd-arch@FreeBSD.org Subject: Re: GSoC project community intro and sync X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 22:43:25 -0000 On Apr 17, 2007, at 3:17 PM, Maxim Zhuravlev wrote: > 2007/4/17, Marcel Moolenaar : > > Thanks for detailed useful reply. > >> As for vtc(4): I've not been working on input devices because of the >> lack of a generic layer. Note that vtc(4) deals with the low-level >> console as much as it deals with user-visible terminals, so from that >> point of view, a user space stack will not address the need for >> having >> console input when there's no (functional) user space -- this >> includes >> early boot, the kernel debugger and single-user mode. I therefore >> doubt >> that it will sufficiently (or at all) solve problems we already have. > > Yup. That's what I'm thinking about right now. > One of possible decisions is to move stacking into the kernel and have > an optional usermode part 'stacked' through a 2 'stub' drivers. That's a possibility. I think it's reasonable to not provide a fully-fledged stack when there's no user space. For example, while i18n and l10n are important, I think that an english-only or a Latin-only fallback mode makes matters simpler in case of an emergency. The user interacting with the boot process or working in single user mode is not an average user and can be expected to adjust to the more limited fallback mode. The question becomes to what extend the stack would live in kernel space and to what extend there will be duplication or control from user space. >> Also, while multiplexing is an important feature I think that de- >> multiplexing is important too. > > I guess, demux can be done by 'top' driver or by drivers layout. There > are several ways, that have little impact on the total design. Unfortunately, this goes beyond just input-stack only. A terminal consists typically of input and output devices and can even include audio devices for the historical beeps, keyclicks and other audible cues. There needs to be a higher entity, like vtc(4), that manages terminals and that will be in control of bundling devices into a functional terminal. This would imply that any logic to control the bundling would be part of that higher entity and not of the input stack itself. This would significantly alter the design of the input stack if the design of the input stack incorporates such control (as I think is the case here). Not to worry, I'm going to ask you to change your design :-) Just think of it as food for thought. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Tue Apr 17 22:43:32 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1394E16A566 for ; Tue, 17 Apr 2007 22:43:32 +0000 (UTC) (envelope-from maxim.zhuravlev@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id C2BFF13C44C for ; Tue, 17 Apr 2007 22:43:31 +0000 (UTC) (envelope-from maxim.zhuravlev@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1643255nza for ; Tue, 17 Apr 2007 15:43:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=g4UTX2VJo5ADRL45nQYpnnwP99h6hhDMWe4Motnbvoh9QC9X8dfZE9P9XQHdYGP+5X7PaKRfqwDRQa/Lg8tSp9hmw0VK5A9LK4kYoBSGSg7e5IAAYKQ5eL8Sfac9vTj7Ijnb1jNHkOFSclvz1c87qWaSgPtaazk+zW++cczKtLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=SQdXvzm/MX+MRI2g3lEDj8PY1vxRhZmfdbwN/KRayjkYQg1Ntpv0Xo+OhlkUPnnUBuoO5aIZeRgo6HC/s2KZxmRqKQAFx01fQcKNhB0WrijA0qqq7R10+qnsBRtI/OaUqd3ysd38/OSbsBpUppGmXab/HIaHUsh+BXfVPnvuAJA= Received: by 10.114.111.1 with SMTP id j1mr1517982wac.1176848240998; Tue, 17 Apr 2007 15:17:20 -0700 (PDT) Received: by 10.114.234.12 with HTTP; Tue, 17 Apr 2007 15:17:20 -0700 (PDT) Message-ID: Date: Wed, 18 Apr 2007 02:17:20 +0400 From: "Maxim Zhuravlev" Sender: maxim.zhuravlev@gmail.com To: "Marcel Moolenaar" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46250237.000008.20157@mfront8.yandex.ru> X-Google-Sender-Auth: c849bd34e4142d0d Cc: freebsd-hackers@freebsd.org, thIOretic@yandex.ru, nsouch@free.fr, freebsd-arch@freebsd.org Subject: Re: GSoC project community intro and sync X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 22:43:32 -0000 2007/4/17, Marcel Moolenaar : Thanks for detailed useful reply. > As for vtc(4): I've not been working on input devices because of the > lack of a generic layer. Note that vtc(4) deals with the low-level > console as much as it deals with user-visible terminals, so from that > point of view, a user space stack will not address the need for having > console input when there's no (functional) user space -- this includes > early boot, the kernel debugger and single-user mode. I therefore doubt > that it will sufficiently (or at all) solve problems we already have. Yup. That's what I'm thinking about right now. One of possible decisions is to move stacking into the kernel and have an optional usermode part 'stacked' through a 2 'stub' drivers. > Also, while multiplexing is an important feature I think that de- > multiplexing is important too. I guess, demux can be done by 'top' driver or by drivers layout. There are several ways, that have little impact on the total design. Thanks, - Maxim From owner-freebsd-arch@FreeBSD.ORG Wed Apr 18 06:58:09 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5009816A400; Wed, 18 Apr 2007 06:58:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from mail.turbocat.net (mail.turbocat.net [213.133.116.130]) by mx1.freebsd.org (Postfix) with ESMTP id 12D9313C4BF; Wed, 18 Apr 2007 06:58:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: by mail.turbocat.net (Postfix, from userid 1002) id B77A0422ECDB; Wed, 18 Apr 2007 08:28:46 +0200 (CEST) Received: from laptop.lan (c983ABF51.dhcp.bluecom.no [81.191.58.152]) by mail.turbocat.net (Postfix) with ESMTP id D727B422ECD9; Wed, 18 Apr 2007 08:28:45 +0200 (CEST) From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Wed, 18 Apr 2007 08:28:25 +0200 User-Agent: KMail/1.9.5 References: <46250237.000008.20157@mfront8.yandex.ru> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704180828.25357.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar , thioretic@freebsd.org, nsouch@free.fr, thIOretic@yandex.ru Subject: Re: GSoC project community intro and sync X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 06:58:09 -0000 Hi, My input in this regard is: 1) The new stack must be detach safe. I.E. no race conditions at detatch. 2) The stack must be able to take an arbitrary mutex, that is provided by the low level device driver, and not just Giant. --HPS From owner-freebsd-arch@FreeBSD.ORG Wed Apr 18 11:25:58 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9364516A403 for ; Wed, 18 Apr 2007 11:25:58 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id B7BDE13C43E for ; Wed, 18 Apr 2007 11:25:50 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3IBPhl2044746; Wed, 18 Apr 2007 15:25:43 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3I8vSJB041121; Wed, 18 Apr 2007 12:57:28 +0400 (MSD) (envelope-from yar) Date: Wed, 18 Apr 2007 12:57:28 +0400 From: Yar Tikhiy To: Pawel Jakub Dawidek Message-ID: <20070418085727.GB40826@comp.chem.msu.su> References: <20070407120656.GD63916@garage.freebsd.pl> <20070409145620.GF76673@garage.freebsd.pl> <200704091601.27454.max@love2party.net> <20070409163456.GJ76673@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070409163456.GJ76673@garage.freebsd.pl> User-Agent: Mutt/1.5.9i Cc: Max Laier , freebsd-arch@freebsd.org Subject: Re: Host ID. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 11:25:58 -0000 On Mon, Apr 09, 2007 at 06:34:56PM +0200, Pawel Jakub Dawidek wrote: > On Mon, Apr 09, 2007 at 04:01:22PM +0200, Max Laier wrote: > > On Monday 09 April 2007 16:56, Pawel Jakub Dawidek wrote: > > > On Sat, Apr 07, 2007 at 02:06:56PM +0200, Pawel Jakub Dawidek wrote: > > > > Hi. > > > > > > > > After initial discussion on IRC, I'd like to propose an addition... > > > > I want to use it with ZFS, but I thought it may be useful in general, > > > > so here it goes: > > > > > > > > I'd like to assign a unique ID to the system on first boot. > > > > > > > > When system starts, /etc/rc.d/hostid script checks if /hostid file > > > > exists, if it doesn't, it creates it via 'uuidgen > /hostid'. > > > > > > > > It will also set kern.hostuuid sysctl to this value and first four > > > > bytes of MD5(kern.hostuuid) will be stored in kern.hostid. It will > > > > allow to use gethostid(3). > > > > > > > > If root file system is read-only, different uuid will be genrated on > > > > each boot. Not sure if anything better can be done here. > > > > > > > > As I said, I think it may be genrally useful. Imagine using it with > > > > magic/variant symlinks, for example. > > > > > > Here is the patch: > > > > > > http://people.freebsd.org/~pjd/patches/hostid.patch > > > > > > Any objections? > > > > I suppose: > > > > > Index: usr.bin/uuidgen/Makefile > > > ... > > > +BINDIR= /bin > > > > will be fixed by (repo)copy for the real commit? Otherwise, no. > > kan suggested not to do it: "respect CVS handicaps, please...." :) It can be repocopied some day in future, after all the stuff settles. Perhaps we should grep src/usr.bin for moved pieces and submit a collective usr.bin->bin repocopy request to the repomeisters. I have the repocopy of pkill in my personal list, which has been happy in /bin for quite a while now but still has its sources in usr.bin. -- Yar From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 09:31:16 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4D7E16A404; Thu, 19 Apr 2007 09:31:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 51CFA13C46E; Thu, 19 Apr 2007 09:31:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C5AC447413; Thu, 19 Apr 2007 05:31:15 -0400 (EDT) Date: Thu, 19 Apr 2007 10:31:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Diomidis Spinellis In-Reply-To: <46231C64.9010707@aueb.gr> Message-ID: <20070419101815.Y2913@fledge.watson.org> References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> <46231C64.9010707@aueb.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 09:31:16 -0000 On Mon, 16 Apr 2007, Diomidis Spinellis wrote: > Robert Watson wrote: > >>>> What do you think of the idea of changing the file format a little to >>>> include a short file header at the front, and that the first field of >>>> that head is zero-filled u_int32_t, and the second a version number? >>>> Right now, the first field of the acct structure is the name of the >>>> command, which will always be a non-nul string, so always have a first >>>> character non-nul. If we see non-nul data in the file header's first >>>> field, we use the old structure layout, and otherwise we check the >>>> version number and use the new layout? This would provide backwards >>>> compatibility for reading old accounting data, which I would think would >>>> generally be desirable, and allow us to explicitly version the file in >>>> the future. >> >> The sites I know of that use accounting don't care about CPU use in the >> sa(8) sense at all. They care about tracking commands run. While acct(5) >> doesn't do this extraordinarily well, it does it well enough to allow basic >> command execution logging and analysis. Hence the desire to be able to >> continue readding preserved acct(5) data files in the future. > > I see three options for satisfying this requirement. > > One is to move the existing acct.h into usr.bin/lastcomm, and add to > lastcomm(1) and option to read legacy files. I don't like this approach, > because it doesn't include sa(8) in the picture, and, more importantly, it > doesn't scale well for future changes. Every time we change the type of a > field of acct.h (for example widening ac_gid) we will have to add > architecture-specific code in the legacy file reading module. If we're willing to assume architectures can only read their own accounting files (the status quo), the above argument doesn't really make sense. You end up with a series of versions of "struct acct", and that code is architecture-neutral. Thinking about it more, I'm not sure a per file header is even required or desired (as I had previously suggested), simply a per-record versioning scheme, allowing a reboot onto a new kernel to continue to write to the existing accounting data. Read the first 16 bytes, if the first byte is non-0 then it's the original "struct acct" layout, and otherwise the second byte is the version number to use. Or in the interests of forward compatibility, include a length parameter in another 16 bytes so you can skip over records if necessary in order to allow the kernel to move back and forward across file versions if there's a problem after the upgrade. > A variation of the above approach would be to create a library for reading > legacy accounting data formats. I think this is an overkill, given that the > two users are sa(8) and lastcomm(1), and of the two lastcomm appears to be > really needed. Sounds like overkill. All you really need is a common routine to return the next record in the current native version given a file descriptor for the open file, and that one routine can handle the versioning concerns easily. No need to have a library, just compile a common .c file from the lastcomm directory into the sa directory (or vice versa). Notice that sa's decoding routing already does conversion from the file type to C types for computation. > The approach I favor is to add to lastcomm an option to dump an accounting > file in text format, and a second option to read text accounting data from > stdin and write it out in the current accounting file format. Users can > then either store accounting data in (compressed) text files, or pipe them > through a pipeline that will transform the legacy format into the current > one. (In the latter case they will need to keep through an upgrade a > lastcomm(1) binary compiled to read the legacy format - I can provide the > appropriate cvs incantation in UPDATING). This approach also simplifies the > writing of test cases. You're putting the burden on the people with data they need to preserve to deal with checking out specific revisions of accounting source code from CVS, get it building on whatever the current rev is (perhaps requiring a buildworld to get build tools and libraries), etc? Your basic assumption in all of this is that no one uses or preserves accounting data, and I think that is a false assumption. On all of my server boxes, I keep at least five days of back accounting data, and I know of sites that keep back accounting data for months or years. I don't think you should be assuming no one cares about this data and breaking compatibility. Since there's a structured file format, it's easy to provide compatibility (and we can make it easier in the future by adding versioning information this time). I certainly don't object to the text export, but I don't think it really addresses the problem of backward compatibility at all. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 10:35:56 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B82AB16A400; Thu, 19 Apr 2007 10:35:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 91C3313C455; Thu, 19 Apr 2007 10:35:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0107647299; Thu, 19 Apr 2007 06:35:56 -0400 (EDT) Date: Thu, 19 Apr 2007 11:35:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Diomidis Spinellis In-Reply-To: <20070419101815.Y2913@fledge.watson.org> Message-ID: <20070419113528.X2913@fledge.watson.org> References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> <46231C64.9010707@aueb.gr> <20070419101815.Y2913@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 10:35:56 -0000 On Thu, 19 Apr 2007, Robert Watson wrote: > If we're willing to assume architectures can only read their own accounting > files (the status quo), the above argument doesn't really make sense. You > end up with a series of versions of "struct acct", and that code is > architecture-neutral. Thinking about it more, I'm not sure a per file > header is even required or desired (as I had previously suggested), simply a > per-record versioning scheme, allowing a reboot onto a new kernel to > continue to write to the existing accounting data. Read the first 16 bytes, > if the first byte is non-0 then it's the original "struct acct" layout, and > otherwise the second byte is the version number to use. Or in the interests > of forward compatibility, include a length parameter in another 16 bytes so > you can skip over records if necessary in order to allow the kernel to move > back and forward across file versions if there's a problem after the > upgrade. s/16 bytes/16 bits/ was intended in the above. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 17:29:17 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7DAA16A400; Thu, 19 Apr 2007 17:29:17 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from blue.servers.aueb.gr (blue.servers.aueb.gr [195.251.255.132]) by mx1.freebsd.org (Postfix) with ESMTP id 466B513C455; Thu, 19 Apr 2007 17:29:16 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from [195.251.249.152] ([::ffff:195.251.249.142]) by blue.servers.aueb.gr with esmtp; Thu, 19 Apr 2007 20:29:15 +0300 id 000D11F1.4627A6EB.0000054C Message-ID: <4627A6C3.2070409@aueb.gr> Date: Thu, 19 Apr 2007 20:28:35 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Robert Watson References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> <46231C64.9010707@aueb.gr> <20070419101815.Y2913@fledge.watson.org> In-Reply-To: <20070419101815.Y2913@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 17:29:17 -0000 Robert Watson wrote: > If we're willing to assume architectures can only read their own > accounting files (the status quo), the above argument doesn't really > make sense. You end up with a series of versions of "struct acct", and > that code is architecture-neutral. Thinking about it more, I'm not sure > a per file header is even required or desired (as I had previously > suggested), simply a per-record versioning scheme, allowing a reboot > onto a new kernel to continue to write to the existing accounting data. > Read the first 16 bytes, if the first byte is non-0 then it's the > original "struct acct" layout, and otherwise the second byte is the > version number to use. Or in the interests of forward compatibility, > include a length parameter in another 16 bytes so you can skip over > records if necessary in order to allow the kernel to move back and > forward across file versions if there's a problem after the upgrade. I will work on developing a mechanism for backwards compatibility. Adding a version and length field in each record as you now propose is I think the way to go. However, it is not trivial, because lastcomm(1) often reads the file backwards. One approach would be to add a flag in ac_flags indicating a new version, and second copy of the length field before ac_flags. Thus, the new structure would be something like: #define AC_COMM_LEN 16 struct acct { char ac_zero; /* zero identifies new version */ char ac_version; /* record version number */ u_int16_t ac_len; /* record length */ /* Business as usual: */ char ac_comm[AC_COMM_LEN]; /* command name */ comp_t ac_utime; /* user time */ comp_t ac_stime; /* system time */ comp_t ac_etime; /* elapsed time */ time_t ac_btime; /* starting time */ uid_t ac_uid; /* user id */ gid_t ac_gid; /* group id */ u_int16_t ac_mem; /* average memory usage */ comp_t ac_io; /* count of IO blocks */ __dev_t ac_tty; /* controlling tty */ /* Changes here: */ u_int16_t ac_len2; /* record length */ #define AFORK 0x01 /* forked but not exec'ed */ /* ASU is no longer supported */ #define ASU 0x02 /* used super-user permissions */ #define ACOMPAT 0x04 /* used compatibility mode */ #define ACORE 0x08 /* dumped core */ #define AXSIG 0x10 /* killed by a signal */ #define ANVER 0x20 /* new record version */ u_int8_t ac_flag; /* accounting flags */ }; This structure allows the file to be read in both directions, and also provides backwards compatibility. Diomidis From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 20:25:10 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 376C816A401; Thu, 19 Apr 2007 20:25:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0AAF413C46A; Thu, 19 Apr 2007 20:25:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 47B0546D68; Thu, 19 Apr 2007 16:25:09 -0400 (EDT) Date: Thu, 19 Apr 2007 21:25:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Diomidis Spinellis In-Reply-To: <4627A6C3.2070409@aueb.gr> Message-ID: <20070419212253.L2913@fledge.watson.org> References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> <46231C64.9010707@aueb.gr> <20070419101815.Y2913@fledge.watson.org> <4627A6C3.2070409@aueb.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 20:25:10 -0000 On Thu, 19 Apr 2007, Diomidis Spinellis wrote: > I will work on developing a mechanism for backwards compatibility. > > Adding a version and length field in each record as you now propose is I > think the way to go. However, it is not trivial, because lastcomm(1) often > reads the file backwards. One approach would be to add a flag in ac_flags > indicating a new version, and second copy of the length field before > ac_flags. Thus, the new structure would be something like: Are there any alignment/padding considerations we should be taking into account with the last two fields to make sure they are consistently aligned with respect to the end of the record as new fields are added to the middle? Robert N M Watson Computer Laboratory University of Cambridge > > #define AC_COMM_LEN 16 > struct acct { > char ac_zero; /* zero identifies new version */ > char ac_version; /* record version number */ > u_int16_t ac_len; /* record length */ > > > /* Business as usual: */ > char ac_comm[AC_COMM_LEN]; /* command name */ > comp_t ac_utime; /* user time */ > comp_t ac_stime; /* system time */ > comp_t ac_etime; /* elapsed time */ > time_t ac_btime; /* starting time */ > uid_t ac_uid; /* user id */ > gid_t ac_gid; /* group id */ > u_int16_t ac_mem; /* average memory usage */ > comp_t ac_io; /* count of IO blocks */ > __dev_t ac_tty; /* controlling tty */ > > > /* Changes here: */ > u_int16_t ac_len2; /* record length */ > > #define AFORK 0x01 /* forked but not exec'ed */ > /* ASU is no longer supported */ > #define ASU 0x02 /* used super-user permissions */ > #define ACOMPAT 0x04 /* used compatibility mode */ > #define ACORE 0x08 /* dumped core */ > #define AXSIG 0x10 /* killed by a signal */ > #define ANVER 0x20 /* new record version */ > u_int8_t ac_flag; /* accounting flags */ > }; > > This structure allows the file to be read in both directions, and also > provides backwards compatibility. > > Diomidis > From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 21:15:04 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 002D616A406; Thu, 19 Apr 2007 21:15:03 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9930513C4BB; Thu, 19 Apr 2007 21:15:03 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.60.100]) by phk.freebsd.dk (Postfix) with ESMTP id EE31017380; Thu, 19 Apr 2007 21:15:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l3JLF1gO046944; Thu, 19 Apr 2007 21:15:01 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 19 Apr 2007 21:25:09 +0100." <20070419212253.L2913@fledge.watson.org> Date: Thu, 19 Apr 2007 21:15:01 +0000 Message-ID: <46943.1177017301@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Diomidis Spinellis , arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 21:15:04 -0000 In message <20070419212253.L2913@fledge.watson.org>, Robert Watson writes: >> __dev_t ac_tty; /* controlling tty */ This field is useless, nobody uses hardwired RS-232 terminals anymore. What we should do is add a systemcall or sysctl, so session creators like getty, sshd and similar can install a session indentifying string on the session, and then dump that in the accounting. sshd would log IP+port and possibly also credential used for auth. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 21:22:10 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE8A416A400; Thu, 19 Apr 2007 21:22:10 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 3D44613C448; Thu, 19 Apr 2007 21:22:09 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id l3JLM7gP027196; Fri, 20 Apr 2007 00:22:07 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3JLM7mG028876; Fri, 20 Apr 2007 00:22:07 +0300 Received: from [192.168.136.22] (ppp121-97.adsl.forthnet.gr [193.92.228.97]) by MX-IN-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3JLLxtq019388; Fri, 20 Apr 2007 00:22:00 +0300 Authentication-Results: MX-IN-02.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <4627DD51.9020003@aueb.gr> Date: Fri, 20 Apr 2007 00:21:21 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Poul-Henning Kamp References: <46943.1177017301@critter.freebsd.dk> In-Reply-To: <46943.1177017301@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Robert Watson , re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 21:22:10 -0000 Poul-Henning Kamp wrote: > In message <20070419212253.L2913@fledge.watson.org>, Robert Watson writes: > >>> __dev_t ac_tty; /* controlling tty */ > > This field is useless, nobody uses hardwired RS-232 terminals > anymore. > > What we should do is add a systemcall or sysctl, so session creators > like getty, sshd and similar can install a session indentifying string > on the session, and then dump that in the accounting. > > sshd would log IP+port and possibly also credential used for auth. > Isn't this purpose mostly served by joining the accounting record with wtmp on the ll_line field to obtain the IP address from the ll_host field? From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 21:42:40 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5530B16A415; Thu, 19 Apr 2007 21:42:40 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 95F2713C4EE; Thu, 19 Apr 2007 21:42:35 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l3JLQiJ3003749; Fri, 20 Apr 2007 07:26:44 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l3JLQiFH003748; Fri, 20 Apr 2007 07:26:44 +1000 (EST) (envelope-from peter) Date: Fri, 20 Apr 2007 07:26:44 +1000 From: Peter Jeremy To: Poul-Henning Kamp Message-ID: <20070419212644.GG828@turion.vk2pj.dyndns.org> References: <20070419212253.L2913@fledge.watson.org> <46943.1177017301@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <46943.1177017301@critter.freebsd.dk> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Diomidis Spinellis , arch@freebsd.org, Robert Watson , re@freebsd.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 21:42:40 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Apr-19 21:15:01 +0000, Poul-Henning Kamp wrote: >In message <20070419212253.L2913@fledge.watson.org>, Robert Watson writes: > >>> __dev_t ac_tty; /* controlling tty */ > >This field is useless, nobody uses hardwired RS-232 terminals >anymore. > >What we should do is add a systemcall or sysctl, so session creators >like getty, sshd and similar can install a session indentifying string >on the session, and then dump that in the accounting. In theory, something that creates a session should be logging a utmp record that links the assigned PTY to the session initiator. The PTY name reflects the session identifier and the utmp record can be used to work out who/how the session was initiated. This approach seems more reasonable than recording complete session information in each raw accounting record. In practice, not all sessions have utmp records and many utilities are not recording logouts. Fixing this and maybe adding information relating to credentials would seem to be less intrusive than modifying ac_tty. --=20 Peter Jeremy --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGJ96U/opHv/APuIcRApqMAJ9euT/gB2ASzOtd4pCWX8r6pYA+WACfU/8h e96wCQxnsGmp2L5zQ80zi1c= =Q+kH -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 21:46:36 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DC2C16A402; Thu, 19 Apr 2007 21:46:36 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 1A34913C469; Thu, 19 Apr 2007 21:46:35 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l3JLkYvR025405; Fri, 20 Apr 2007 00:46:34 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3JLkYm4032299; Fri, 20 Apr 2007 00:46:34 +0300 Received: from [192.168.136.22] (ppp121-97.adsl.forthnet.gr [193.92.228.97]) by MX-IN-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3JLkVfn022770; Fri, 20 Apr 2007 00:46:32 +0300 Authentication-Results: MX-IN-01.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <4627E311.6080500@aueb.gr> Date: Fri, 20 Apr 2007 00:45:53 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Robert Watson References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> <46231C64.9010707@aueb.gr> <20070419101815.Y2913@fledge.watson.org> <4627A6C3.2070409@aueb.gr> <20070419212253.L2913@fledge.watson.org> In-Reply-To: <20070419212253.L2913@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 21:46:36 -0000 Robert Watson wrote: > > On Thu, 19 Apr 2007, Diomidis Spinellis wrote: > >> I will work on developing a mechanism for backwards compatibility. >> >> Adding a version and length field in each record as you now propose is >> I think the way to go. However, it is not trivial, because >> lastcomm(1) often reads the file backwards. One approach would be to >> add a flag in ac_flags indicating a new version, and second copy of >> the length field before ac_flags. Thus, the new structure would be >> something like: > > Are there any alignment/padding considerations we should be taking into > account with the last two fields to make sure they are consistently > aligned with respect to the end of the record as new fields are added to > the middle? Thanks for pointing this out. True, we can't depend on ac_flag being in a fixed offset from the end of the record. On i386 the situation is: Old size=48 offsetof ac_flag=44 end-offset=4 New size=60 offsetof ac_flag=58 end-offset=2 and on amd64: Old size=56 offsetof ac_flag=48 end-offset=8 New size=64 offsetof ac_flag=62 end-offset=2 If we follow the route of allowing the records to be read from both ends, we'll have to think of a construct that will portably maintain ac_flags at the same offset from the end as in the old struct acct. Proposals welcomed! - dds PS The proposed layout in my previous email didn't include the changes for the fields. This is the correct layout I used for the above calculations: struct nacct { u_int8_t ac_zero; /* zero identifies new version */ u_int8_t ac_version; /* record version number */ u_int16_t ac_len; /* record length */ char ac_comm[AC_COMM_LEN]; /* command name */ float ac_utime; /* user time */ float ac_stime; /* system time */ float ac_etime; /* elapsed time */ time_t ac_btime; /* starting time */ uid_t ac_uid; /* user id */ gid_t ac_gid; /* group id */ float ac_mem; /* average memory usage */ float ac_io; /* count of IO blocks */ __dev_t ac_tty; /* controlling tty */ u_int16_t ac_len2; /* record length */ u_int8_t ac_flag; /* accounting flags */ }; From owner-freebsd-arch@FreeBSD.ORG Thu Apr 19 22:27:48 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B948316A407 for ; Thu, 19 Apr 2007 22:27:48 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 3A1DB13C43E for ; Thu, 19 Apr 2007 22:27:48 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 64045 invoked by uid 2001); 19 Apr 2007 22:01:06 -0000 Date: Thu, 19 Apr 2007 17:01:06 -0500 From: "Rick C. Petty" To: Diomidis Spinellis Message-ID: <20070419220106.GA63814@keira.kiwi-computer.com> References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> <46231C64.9010707@aueb.gr> <20070419101815.Y2913@fledge.watson.org> <4627A6C3.2070409@aueb.gr> <20070419212253.L2913@fledge.watson.org> <4627E311.6080500@aueb.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4627E311.6080500@aueb.gr> User-Agent: Mutt/1.4.2.1i Cc: arch@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 22:27:48 -0000 On Fri, Apr 20, 2007 at 12:45:53AM +0300, Diomidis Spinellis wrote: > > If we follow the route of allowing the records to be read from both > ends, we'll have to think of a construct that will portably maintain > ac_flags at the same offset from the end as in the old struct acct. > Proposals welcomed! How about rearranging the struct to have the fixed-sized fields first, followed by the variable-sized fields. In fact I thought that was the recommended practice.. i.e.: > struct nacct { > u_int8_t ac_zero; /* zero identifies new version */ > u_int8_t ac_version; /* record version number */ > u_int16_t ac_len; /* record length */ > > char ac_comm[AC_COMM_LEN]; /* command name */ > u_int16_t ac_len2; /* record length */ > u_int8_t ac_flag; /* accounting flags */ > float ac_utime; /* user time */ > float ac_stime; /* system time */ > float ac_etime; /* elapsed time */ > time_t ac_btime; /* starting time */ > uid_t ac_uid; /* user id */ > gid_t ac_gid; /* group id */ > float ac_mem; /* average memory usage */ > float ac_io; /* count of IO blocks */ > __dev_t ac_tty; /* controlling tty */ -- Rick C. Petty From owner-freebsd-arch@FreeBSD.ORG Fri Apr 20 05:39:21 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F58416A401 for ; Fri, 20 Apr 2007 05:39:21 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-04.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id D413513C468 for ; Fri, 20 Apr 2007 05:39:20 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.13.8/8.13.8) with ESMTP id l3K5dJpp019332; Fri, 20 Apr 2007 08:39:19 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3K5dIMN019982; Fri, 20 Apr 2007 08:39:18 +0300 Received: from [192.168.136.22] (ppp121-97.adsl.forthnet.gr [193.92.228.97]) by MX-IN-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3K5d9IS011401; Fri, 20 Apr 2007 08:39:12 +0300 Authentication-Results: MX-IN-02.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <462851D5.3020703@aueb.gr> Date: Fri, 20 Apr 2007 08:38:29 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <461958CC.4040804@aueb.gr> <20070414170218.M76326@fledge.watson.org> <4621E826.6050306@aueb.gr> <20070415105157.J84174@fledge.watson.org> <46231C64.9010707@aueb.gr> <20070419101815.Y2913@fledge.watson.org> <4627A6C3.2070409@aueb.gr> <20070419212253.L2913@fledge.watson.org> <4627E311.6080500@aueb.gr> <20070419220106.GA63814@keira.kiwi-computer.com> In-Reply-To: <20070419220106.GA63814@keira.kiwi-computer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 05:39:21 -0000 Rick C. Petty wrote: > On Fri, Apr 20, 2007 at 12:45:53AM +0300, Diomidis Spinellis wrote: >> If we follow the route of allowing the records to be read from both >> ends, we'll have to think of a construct that will portably maintain >> ac_flags at the same offset from the end as in the old struct acct. >> Proposals welcomed! > > How about rearranging the struct to have the fixed-sized fields first, > followed by the variable-sized fields. In fact I thought that was the > recommended practice.. The new structure has to provide backwards compatibility with the old structure for a program reading a single record either from the beginning of a file or from its end (backwards). This is why ac_flag and ac_len2 (which is a copy of ac_len) have to be in the end. A program reading backwards (e.g. lastcomm(1)) will first read ac_flag. If ANVER is set, it will then read ac_len2, and then the rest of the structure. It will the interpret the structure based on ac_version. If ANVER is not set, the structure is in the old format and the program will read the old struct acct. A program reading forwards will first examine ac_zero. If it is zero it will process the structure based on ac_len and ac_version. Otherwise the structure is in the old format and the program will read the old struct acct. - dds > i.e.: > >> struct nacct { >> u_int8_t ac_zero; /* zero identifies new version */ >> u_int8_t ac_version; /* record version number */ >> u_int16_t ac_len; /* record length */ >> >> char ac_comm[AC_COMM_LEN]; /* command name */ >> u_int16_t ac_len2; /* record length */ >> u_int8_t ac_flag; /* accounting flags */ > >> float ac_utime; /* user time */ >> float ac_stime; /* system time */ >> float ac_etime; /* elapsed time */ >> time_t ac_btime; /* starting time */ >> uid_t ac_uid; /* user id */ >> gid_t ac_gid; /* group id */ >> float ac_mem; /* average memory usage */ >> float ac_io; /* count of IO blocks */ >> __dev_t ac_tty; /* controlling tty */ > > -- Rick C. Petty From owner-freebsd-arch@FreeBSD.ORG Fri Apr 20 05:42:33 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E176E16A400; Fri, 20 Apr 2007 05:42:33 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD2713C480; Fri, 20 Apr 2007 05:42:33 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.60.100]) by phk.freebsd.dk (Postfix) with ESMTP id 1DBA817380; Fri, 20 Apr 2007 05:42:31 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l3K5gV2r048539; Fri, 20 Apr 2007 05:42:31 GMT (envelope-from phk@critter.freebsd.dk) To: Diomidis Spinellis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 20 Apr 2007 00:21:21 +0300." <4627DD51.9020003@aueb.gr> Date: Fri, 20 Apr 2007 05:42:31 +0000 Message-ID: <48538.1177047751@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@FreeBSD.org, Robert Watson , re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 05:42:34 -0000 In message <4627DD51.9020003@aueb.gr>, Diomidis Spinellis writes: >Poul-Henning Kamp wrote: >> In message <20070419212253.L2913@fledge.watson.org>, Robert Watson writes: >> >>>> __dev_t ac_tty; /* controlling tty */ >> >> This field is useless, nobody uses hardwired RS-232 terminals >> anymore. >> >> What we should do is add a systemcall or sysctl, so session creators >> like getty, sshd and similar can install a session indentifying string >> on the session, and then dump that in the accounting. >> >> sshd would log IP+port and possibly also credential used for auth. >> > >Isn't this purpose mostly served by joining the accounting record with >wtmp on the ll_line field to obtain the IP address from the ll_host field? The IP number alone is not a "session identifier", you want the ID of the credential that gave access as well. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Apr 20 06:02:46 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3318316A400; Fri, 20 Apr 2007 06:02:46 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id A716813C448; Fri, 20 Apr 2007 06:02:45 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id l3K62iTS029771; Fri, 20 Apr 2007 09:02:44 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3K62haT032115; Fri, 20 Apr 2007 09:02:43 +0300 Received: from [192.168.136.22] (ppp121-97.adsl.forthnet.gr [193.92.228.97]) by MX-IN-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3K62aYJ009244; Fri, 20 Apr 2007 09:02:37 +0300 Authentication-Results: MX-IN-02.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <46285755.3010208@aueb.gr> Date: Fri, 20 Apr 2007 09:01:57 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Poul-Henning Kamp References: <48538.1177047751@critter.freebsd.dk> In-Reply-To: <48538.1177047751@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Robert Watson , re@FreeBSD.org Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 06:02:46 -0000 Poul-Henning Kamp wrote: > In message <4627DD51.9020003@aueb.gr>, Diomidis Spinellis writes: >> Poul-Henning Kamp wrote: >>> In message <20070419212253.L2913@fledge.watson.org>, Robert Watson writes: >>> >>>>> __dev_t ac_tty; /* controlling tty */ >>> This field is useless, nobody uses hardwired RS-232 terminals >>> anymore. >>> >>> What we should do is add a systemcall or sysctl, so session creators >>> like getty, sshd and similar can install a session indentifying string >>> on the session, and then dump that in the accounting. >>> >>> sshd would log IP+port and possibly also credential used for auth. >>> >> Isn't this purpose mostly served by joining the accounting record with >> wtmp on the ll_line field to obtain the IP address from the ll_host field? > > The IP number alone is not a "session identifier", you want the ID > of the credential that gave access as well. Agreed. But, still, the credential identifier should be part of wtmp and not burden every accounting record. There is also the problem of processes running without a controlling terminal, like non-interactive ssh commands, crontab jobs, and so on. Let's try to solve this in a next version of the accounting record, which should be a lot easier to implement, once we get this one right. From owner-freebsd-arch@FreeBSD.ORG Sat Apr 21 16:26:40 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98F8A16A401; Sat, 21 Apr 2007 16:26:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 461ED13C459; Sat, 21 Apr 2007 16:26:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l3LGP1Fs071590; Sat, 21 Apr 2007 10:25:01 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 21 Apr 2007 10:25:08 -0600 (MDT) Message-Id: <20070421.102508.1324583897.imp@bsdimp.com> To: ru@FreeBSD.org From: "M. Warner Losh" X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 21 Apr 2007 10:25:01 -0600 (MDT) Cc: arch@FreeBSD.org Subject: md directories in the install X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 16:26:40 -0000 Greetings, I have a need to install boot blocks for the arm. However, there's a lot more variation in the arm world, so I'd like to segregate the boot blocks by platform. boot2 for an at91rm9200 won't work for an xscale, or maybe even other at91rm9200 boards, but the sources to the two boot loaders are liklely 90% common. To that end, I thought I'd place them in /boot/at91, /boot/xscale, /boot/samsung, etc. However, I need to get these directories created to install into somehow, but only for the arm. What's the best way to go about doing that? Warner