From owner-freebsd-arch Sun Mar 3 3:59: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5B90A37B405; Sun, 3 Mar 2002 03:58:55 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA19904; Sun, 3 Mar 2002 22:58:51 +1100 Date: Sun, 3 Mar 2002 22:59:34 +1100 (EST) From: Bruce Evans X-X-Sender: To: "Brian F. Feldman" Cc: Alfred Perlstein , , Subject: Re: Do we want the _SYS_SYSPROTO_H_ junk? In-Reply-To: <200202281314.g1SDE3t50441@green.bikeshed.org> Message-ID: <20020303221043.R65083-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 28 Feb 2002, Brian F. Feldman wrote: > Bruce Evans wrote: > > On Wed, 27 Feb 2002, Brian F. Feldman wrote: > > > > > I want to know if, on new code, we should put them. E.g.: > > > > > > #ifndef _SYS_SYSPROTO_H_ > > > struct open_args { > > > char *path; > > > int flags; > > > int mode; > > > }; > > > #endif > > ... > > The ifdef'ed version is better, if there is to be one at all, because it > > can at least in theory be checked automatically (e.g., by not including > > so that the struct is not declared, but somehow declare > > the function anyway; then compile and check if the compile worked and > > gave the same result). > > However, it doesn't _really_ match what's in sys/sysproto.h because it > doesn't have explicit padding (so could potentially assemble to a different > format for that object, rather than the one expected by the syscall handler). Oops. I forgot about the padding. It defeats simple checks like the above. Putting the padding in MI declarations would be too ugly. > > The second pseudo-declaration of the struct in the comment is bogus. I > > removed the comment globally when I implemented , but it > > came back in a few files in the Lite2 merge. > > So for documentation's sake, since it really is useful to generally see the > real "arguments" to a syscall (or vop, or ...) instead of the opaque one, we > should not have the comment in the declaration itself but keep the one > before it? I'd definitely prefer to have one. Yes. I still prefer it separate from the declaration since it gets in the way less there, but wouldn't change to this style for at least the old vop functions. > > The same few files that have syscallarg() in comments also have SCARG() > > in code. We don't really use either syscallarg() or SCARG(). We just > > require the MD code to arrange the struct so that ordinary struct member > > references work right. I would prefer the MD code to push the struct > > members onto the stack so that no args structs or pseudo-declarations > > of them are required. > > Wouldn't this be not-too-hard to do by declaring an inline function with > some assembly which would push the argument space onto the stack before > struct proc * and then calling the sy_call? The only trouble seems to be > C's general lack of wanting to let you dynamically choose an arbitrary > amount of data onto the stack, unless there are endianness/object layout > concerns. Something like that. I think it needs a function in assembly (or gross hacks in C) but not an inline function. The function would copy the syscall args from wherever they are (normally either on a stack in user space or in an array in the kernel) to wherever they should go (normally onto a stack) and then call the C entry point. Endianness object layout concerns potentially need a different function for each syscall. The only way that I can see to reasonably use inlines is to change all the current syscall functions to inline ones with prototypes like the corresponding user interfaces (no args structs). Also change makesyscalls.sh to generate non-inline functions that call these. E.g., the generated lseek() would be something like: register_t sys_lseek(struct thread *td, struct open_args *uap) { off_t retval; retval = lseek(uap->fd, uap->offset, uap->whence); /* * MD code to assign retval to curthread->td_retval not shown. */ return ((register_t)retval); /* Something to not clobber td_retval. */ } Since lseek() is inline and the above is machine-generated, this is just as (in)efficient as the current code. > > I would keep introducing the ifdefed version of the struct while there > > is still an args struct. > > Why, though, do we declare it with the explicit padding in sys/sysproto.h if > that's just what the machine's compiler will pad it to in the first place? Because it's not what the compiler will pad it with :-). The padding rules are different for function parameters. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 3 4:43: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 8397537B405 for ; Sun, 3 Mar 2002 04:42:29 -0800 (PST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp [IPv6:3ffe:b80:5b0:3:280:c8ff:fe6b:6d73]) by rina.r.dl.itc.u-tokyo.ac.jp (8.12.2/3.7W-rina.r-Nankai-Koya) with ESMTP id g23CgD0j099808 ; Sun, 3 Mar 2002 21:42:14 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.12.2/3.7W-carrots-Keikyu-Kurihama) with ESMTP id g23CfIfu059069 ; Sun, 3 Mar 2002 21:42:08 +0900 (JST) Message-Id: <200203031242.g23CfIfu059069@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Date: Sun, 03 Mar 2002 21:41:18 +0900 From: Seigo Tanimura To: Matthew Dillon Cc: Terry Lambert , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: reclaiming v_data of free vnodes In-Reply-To: <200202260923.g1Q9NkVh093544@rina.r.dl.itc.u-tokyo.ac.jp> References: <200202231556.g1NFu9N9040749@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <200202242041.g1OKfXt95731@apollo.backplane.com> <200202250325.g1P3PVN9092431@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <200202250444.g1P4i8X29005@apollo.backplane.com> <200202251437.g1PEb12R001419@bunko> <3C7A5D24.E11A6693@mindspring.com> <200202251754.g1PHsTs50126@apollo.backplane.com> <200202260923.g1Q9NkVh093544@rina.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Sun_Mar__3_21:41:18_2002-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Multipart_Sun_Mar__3_21:41:18_2002-1 Content-Type: text/plain; charset=US-ASCII Attached is the patch to use the zone allocator for in-core inodes. On Tue, 26 Feb 2002 18:23:45 +0900, Seigo Tanimura said: Seigo> AFAIK, all of ffs, ifs and ext2fs utilize struct inode and Seigo> dinode. They deal with the filesystem-specific data by a union. All of Seigo> the filesystems should thus be able to share a single zone. However, the usage of a few of the members (eg i_spare) depends on the filesystem. So I actually gave a distinct zone for each of ffs, ifs and ext2fs. This also gives the better modularity of the filesystem than a single zone. The patch includes the following optimization to the initialization of a new in-core inode as well: - Do not clear the members filled in *_vget(). - Since NODQUOT is defined as NULL, clear i_dquot only in ufs_reclaim(). Finally, the result of vmstat -mz on cvsup.jp.FreeBSD.org follows the patch. At that time, the host was up for a few hours, during which I took du(1) over the whole cvsup tree. --Multipart_Sun_Mar__3_21:41:18_2002-1 Content-Type: application/octet-stream; type=gzip Content-Disposition: attachment; filename="inodezone2.diff.gz" Content-Transfer-Encoding: base64 H4sIAK0SgjwCA+08aXPbOJaf6V+BTlelJEuydcvHpLdTHXvGu4ndEzu9mZ3qYlEiaGNCkWwe Spxs9rfvew8gCVKkROWoxLvtRBIJ4OF4F94B0haOw3pJeMkODg6dkPN5ZB9G99Hhwrct+jJX TuQH0cGCHVQU7vV6ve2gxs1dws75nA2P2GB2MpmdDIZs2O8P9zqdTmW/6xDDYwnx88+sN+kP u1PWwZ9j9vPPe8wwGP1dvnr+vEvf7dM99nGP7XV+FN7CTWzO/rJaHq6WB3c/rZWZ732PU8Ue y6sSJzrED38XW3EcYn1F7R+JH1s1dfBZ+okXY7Vdj+hlYMWHrvCSd/LbdITLFb5r6qrRXtN4 O/YbA+pEGE+RBvAtSZAvHycTx/clpGDpyvNtQvQDoMutl+AQQznS0LRc118QVWpqqmhS09S4 STi75gEbTtjg+GQ0PRn3EbEDRZFasDI9RiNdKKRMVNIjW2+pHD6uf/vtSSJSzmhMj3k9QeY7 UGT+iSSZN6LJ+Ihk5KiSJski5PbXlpJGSK+WERMWykNvJ6qkIBUYS6uaUCVtuytVcrhNVBn0 x90x6+DPlOgiwdjKD8yY7e9TV1HAF3AfnFZXO8LxVfVeJ20gaQGNsAkil+5PiTLcAySyw332 g3n9j2vzr5evzLPXN8Pza/rBr7OXl+bfTLZ/2BzdkoJVMqBqmiBbNd0V1xnYRqU0IqU06s4I 0TqnZQxdLtP4rpbX2WeoH5zXbIDzmg3VvIQXE5lxVSJuRXGYLGIGxsjC9xy2DxdBe4992OsY BcqyJ+w9ATySpLy8enb2qMsi8Z77TtoL4andZX36P0HDxAh5nADDtFDKqAMaIbVZdiO/ufBW 9SwgaxuzgWxewQqDrayQgm5ihxGhHb6r9GEE1Ps+1GFzCkhzacNeVGzQhA5FiF1JUYbeSI0J UWOyk8XwkG04iRyxjVpiZ2qJz6KWaEYtsrdH04dIrd3NO9f33yRBNZFUVSPyqLY7EyaD27i7 EUkmNSSRVF2niS1Croj1wIgSJfOwkiSyoglBZMtdyZFCfbL/8x3Z2s3RrUVe6qqaoHxDFGaq xwFq4a6tmL2wQsaGbDg46c9O+n0N7eTiTI522dKXSczffV97CC7laAzmYOdopoxCnLxYoG0o TcPVLY+Zaf7aSi07Amb7XTTxzBjsPmU2IqnBTyB7bq2TIPadu0I3qn0G7wibSeC9ngJ/8fT5 86tfzGdn5xeXZ60X5DKgsdllZHky7OFReiP7C0KxsmL4tcL4EXTWqfVOWDbL3O4FwjPJC4oN wNT9AIYrrYHW3SWUTY8miLPp0ZFCmgEGrJEsA2gP/GhKJdiSFjHbh4oue2G+Or9+cXmDV//5 9OLm6j/IJp6/56Hfai0s2w7NuE1NNTho08OOez8lS9VtfB+gCZ6jA1aZNVH2eXmtWf3cfWMB KRzVJrvX2wA6vAUiUbVJ7/U2SWBrLeTdqXIzh7PuYISO5qiPF4QfhVVpMt9Z0R3sNYs3AD8g ShiH+7BOts8uHBbfiUiRvtVmcB3w0PHDJbeZ5YCLBA04A6b0+FuieasN69dA30vkNwRlCCqA q8XtXczmOKsuc7m1Et4tsxRXvRXxHdxghJWtTFirxWKfzbmEdoAxbDa/l7iI7j0a3AEAvGZ3 VhBwL0IIB/ZAFtJIMBOvK+Hf3onFHYzhumxhJREHwMDygDHnXN7r/c7BeLLdewlp85A78PEW PGIroIyaXMuK2FsO/cHCojs/ce32AUEcApYVakWQiZ7IRLHShdMFT+PdjiGQ31vFTtoK/QUO bKdEZk+xEjnHYkAEiV61S+DsmAF4a7V4GPoh9K2T6rcbFKAuQwGROgWLMRjRZY9X4EayH56w fhvkVQU7Bt1hn8Id4+4gjZcbb603PAlaj6v5kSSynlf7VL2/CnDdyAwonMb5y7MzwmaOJ8KO 8R63pyIiQGkGcpDUF6alUtFH6KykDURQTRPs/0ebOwKE/eXTy7+eXZ23UC0gRUHxAYI8u81a INcRB+lWdVTYY6VSgmijDJUGfyyAoYRJ9VjTRTGDv1biReLW49BZOrY+OViiBgM3MCxeykmD pHAnhYNFI2YpFPBYsq+Uv18vAIug2BF3wnskowiEJI3JnwAusUhOUwrqE5CCvIwDGaGIvlLF hWV5C5uvoA6+8yIvWc45Mh+sBuj7IzDk319d3TwF6oAqYS1BjMAE+wsoqddUdQ23nU4bmUF1 i/vvP8XvyCZXz7AN9kSxMKnrSHp/TWIUUN8DzSDiiCGrscWdJTxmgUIhpkMB9kFZgC3ig8oI Wcj/SHgErWEyshtSekLpKZD5uQREbcjvmRXCjshRx7jwDXIHGihyOQ9Qv721RAy/O9hmXq1p 5jW3zDxlmK1Zw8NN1nAGtmYOj3O7bIrBzc50/MUjb8UKEujAuuXhWliODECQD8tdWeFGPwON MUd+tDxLRWkVUiuaGeehIMywIzYcAlpORjPd0q0CWUPmWEPm+Jji+MfVRu59tIjdB51c0REy r6bAvCEJ5tU0GI5OJkd1NJg3IwIlfcfDbxcA+crJFB0lWiKlqngbFbJEyA5UqE+e6FSYDboD sCbkj4qdGwguIqlvddcGNhwwphITdHlIV9DOVrsq7mI5LC2kDl5ts2xbN8QEALPJu8qcNnUf 34XcAoeri2Y3/qXtiCdN8jHIG5N7fp7kWR859H3lIK58YWN9r1Bf7Tymi1LWRjYxz1pyQft7 NrfSlGlW6Qi2/7ljdKrG6NYsGGoRP+A1ldANdqhWZ1rhbaS82RLo4rYAmJreuJXDn0bibvEG ulFfCpJiOxpF54mjvO9Gkpbn0CpKt8lZmgTbQcxq82a6lGXBrO8ob9YIm5FnBeBoxWsIzSu2 4TRvWXEApXYf3wRV2EU2peRDHvlJuODKYHnAqY8CanwntnmwTpK0fCtF0oYVBKnl8w1AOj2m lBKcZttJrQlVR4tiOSZsJc4/n0S2qCPPF5WYNKi+XriVLpXB9GMlJYMqotQE0hsbu6BcK7Ce h9e/kZVVtmEa4l6LsFcVb8P/htOKtWKxIaquJzPkAcdhtVTUppZ2Dayj4/YtI+4o9hOQ/kl3 MC6tM8NZ1IjcDAMUawvu1S24VxtaP5fHOLrsEVxlgXW8romrq37y8DpMrDK6nto/0VzFjHXz J8WMTCeUbS3XB1usyrIrmUAVBmJ5dN+18VgLHvlcM7Wr2mNMqmjhpadi2trqMb9Bf7mxu9UI xcigZnHqtuiapVufpUjKKYpsBjJDMRgNZBB+NO6CVCKTsX3DAGmJ+RLm4royWORYwpXh7bPz p6+e38CS2MIP7oUH48GNBKNJyqA2oEVEzGK33Esw/EgxcSf0lxRbTyIeHiDMITkBOqL2ciS1 MIYLlLjrMlx5l3k2FMR2e6/D1J+ORcPYXwaneR1i1IBC7EEvlgiGGuz0dK2vDNPGPoy3Xi+x Dv3GNlTiqac0Rqs5GnVT7xb4n3jkI+7Gh/swzj77xV8ufcQsiBJGEaExxfgEyDk2OCSPZq/T aCQaYY/VowoD7ZL/VF3gQ+88xAB7JRIRAC8wRyEBCaLQvohdhAAnJ1lyL6bUBmgKPDsoHKA2 daEDV1MgnyaNxlCaoTthuVEFsE4emm/oL3gUpQFRDGem42aUzbSTYZBaQjjKkPkO6TgaB6UH g+zYCn8xFKx70ca+zVcYVia5mkwx8zeYpRFGoyqUj+lAigbryQzNVW+hz7wKZDIDSZop4DSN gVqiMXSR9VQHlTPDUumm/3Z+bV7fPL05vyZGe4zh8aUXY+g+JlmU6x2N8RBjZwRbVrpeCjnz AuVAI9giWlihzSkRRqogCHjIXL7iLvH9gYK99GEPoID2KtMHbegnSFzYHSLmmDAN30NeIVFJ IgV5uBGjRKMNCKVjjI3BdUwSgxjGCvYjLttJGlfTXR7/nHYHAzBkJmP8lcp3TQdIBKIWyMIo UnOStuxtmF2eB25LlbFpFXTu8lZEmP4sBocUW2fcrraspV6WbkWoE3tGVZAonwwGi3J7QNkB HyrGz3f9pDAYhTDmStKmkwHl2KfHGefd+qBo/CQ+LSTcmyXb2X/D5X+dvbyqz6gXV1LKqJcT 6cLkjuO5wntjrixX2CqVndVT0klNrZWYru/dtp2o9xNZQjhXbZIq+KPlVknVDKZDNBA7g8FR nkhfxu/MxMOQYeuxU8xSQlX7/1A2nYzGL59M17r9Brl0FdJc578dUusFdd88s74tqU5uWjGn njLi0ZSi34Nhf5QxIunStxZsGTKn3i7k15265Hpt9nwdJXoWXV/zn0n0UhI9TSijuxbBvuuH YJNRViECKw9FD6x6FFboEgpBSxKdI8XGRGPwwaXDMBz21fMhKpm9nkPfOYOO002T6B9oG0ej gejfIKe+KamOBP+OE+vSFRvT4yCDEdmOMrBtqDghOZpg8QJ/toiBUb/LAxHr2h08cnAYVrcx +OYvbl6j904yogtH/nDG+dd/MqMQ4fEqY0pes5BS9ZGAYxVRqorp1R4HKCQU6Kz/ZKLwXhcX Wavw5//ii/i7SzcI+dGPiVcV12G73K4Jutdh1vA9qQiiPpQETrq8Uki0XLwNo4WQ6DO+YMMZ YnQ8OxlN6jDaMCRKiYJJ9bND4HS9ca05rzqGoUVLv6vjxtMR2RLTaeoaNWOSrTFbRv/q4psX WXzzQotvXuwQ3xQb4psijRiuRwtP1xo2jRNK06tP4YZBGm74II29X8Cmlva32keY41q30s5L PXkqefyE/Q+4GOb11fnNs7NfccfUo1qbw3G0uewUBBOlIBhtH0wuZTyjXXCSRRKqnjdUHmO+ C4rGu6Co3AUvvtguSIs4OpYu2fG40iMTf3pk/x89MvF1PDJR55ENB1KJDgezhv6Y+ML+mPjT H9vuj118uj82VA9RDEfjP72xr37MuZRnV4aaVlJn/2lNKozp47LppzffaPVNZ93hAIykTLxJ YRSUD26Tzy+ub8yzy5uX/2hJGQLORPSegvb5W4Zm0jaUi2I3dxh7BoF+S/kSjqwREbIWaFHA PgJU+QCy1AUB7+Kx64/0AFirLTtR8mlo0mDIIdFsNG6eXjz/e3lCHnSDx5RO8TUQ6Xklhu/a Ya6IYqm25dIMuR2xfXWeH9fxGxVZUeQvBChTW25WOTcc1HQgo9tZB8jZkmUuDq+U/k1AJcaj IRp3ZC1RfggvItAgnMMGBYiS3UNvZgyagvqlds/4SiyqJsYL86KH5AhQCiLBIhkE5briexT/ IhBDgSSQNMRMQNADXgOPcw8XwTCd7XLMmeBIGNX2hA/kAxnF3SefGOJaZn7VpFJsYfYb1Ae1 x+BRoVI+dTQHHDk+26fnJrCdfOeDbPpRztpMULFkrOFEhio+cCK9AvvIqvAmpxsjfUJ0I8WS KZ7fiW2eUa1sm4Q8ygj4R2LZRL+lb4eKMi+BMhFiQiafkPKXMGNg8ChFcDoqMoSDo9IFiQ2m O4Ak8/uY92QHxDXIqgoYFBvK6DE9Bn101B0OpYLW2SkCR4L/c/Q7Tej169fMgonDTnoPvofX o1owqWFm8gkHKV4sN4ptEZKeRITIS8IDCjVKLkK6VnjLsSFfxH4oJBtIMX+hBDsJ0CwDfSoV IorrDiKu9jhDCSP2/bly2vkEOe18qvB1PkX4cJEN5aizSY46zeWoo8tRp06OOpvkqPN5cpRu 1YgaYE8MKwBjET1gx+auk9rXW3dQdJ2shZsFUgplm3bRrBHtoxhgGhyzwdHJCPbGaflUWQlg Y0SKIoDj6rd9gHhXPj6hRzu+4QMUuLxtAawUFfOlFaxhXRZuQ7ts1dR+0SEahQJ3P3GcPT// AJ4fSlFSPE9fKt1GAf08/b9bHvA9kmBQdZ6+DPLpNPhixym/Nv4p8DJT526y0wDo7ipXRO2V P0g3lhxf6EAVm9JfJQ9V+SY96eXmIYUu++38+uYKHG9VSGGudpX/K93f+ubSIc67Xn9qta+H mvoyutSIxUpR/3LxNiarj+APa7msWdQ/eyHMQ4n6p8uTrcsIVaXb8Kma7YLOWpACNje90QVs kTf8Qb/ySMdHKetSLt5GgV0Oom+HKdBgU9blwdAgf1FNdnxv21OaIHLl1El6kuoRXMh0xSP9 JrcmKW+yx9CYBFvyhfUGI5+5zcz8gIdWDKa15dIZYTwKSN4M+Ci2z6xYnSvEM6UHDRnIq+Qf rxn7aEnnosE5q+UerwHzTCnRMZ19VXWIWXDh+OpnyyuW1nNxxXWpwi0IU63WDcVRv8ZQzCA2 oUu9fyg7UBuLJZ7FxTN2eKm7MORgSb+EBIBhA3DNlyKWjgydagbIPyiKswYqgbJzytQoi7hM x3LUyFpxe2m9I87F88BG6sP31FBapR58Kp6LLJgOueNJgV7tqKF0APODysqEkINqEJTVyoJD FQcQFXKyUkal/5bDtHBK8pnzdvWzwr7jmHVPmeqF+aOmes/qTUKb+5ZZzqqnVv8XcjwYJpRd AAA= --Multipart_Sun_Mar__3_21:41:18_2002-1 Content-Type: text/plain; charset=US-ASCII --Multipart_Sun_Mar__3_21:41:18_2002-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="vmstat-mz.inodezone.txt" Content-Transfer-Encoding: 7bit Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 16 1147 1413 11388727 1280 9391 32 1795 5885 1049592 640 1668 64 377911 63561 14943019 320 176 128 59718 51130 1628292 160 17048 256 3945 38407 1457347 80 94181 512 4643 114285 1167114 40 47681 1K 93 2615 389590 20 195559 2K 19 263 11722 10 8816 4K 150 3 2074 5 0 8K 4 4 1695 5 0 16K 15 0 15 5 0 32K 3 0 9 5 0 64K 1 0 1 5 0 128K 2 0 2 5 0 256K 2 0 2 5 0 512K 6 0 6 5 0 Memory usage type by bucket size Size Type(s) 16 nexusdev, UFS dirhash, newdirblk, p1003.1b, NFSV3 srvdesc, ip6_moptions, in6_multi, igmp, routetbl, ether_multi, vnodes, mount, pcb, soname, rman, mbufmgr, bus, sysctloid, sysctl, ip6ndp, temp, devbuf, linker, atexit, proc-args, acpica, acpidev, DEVFS 32 atkbddev, UFS dirhash, dirrem, mkdir, diradd, freefile, freefrag, indirdep, bmsafemap, newblk, tseg_qent, in_multi, routetbl, ether_multi, ifaddr, vnodes, cluster_save buffer, pcb, soname, sbuf, mbufmgr, eventhandler, bus, SWAP, sysctloid, sysctl, uidinfo, temp, devbuf, lockf, linker, proc-args, sigio, acpica, pfs_vncache 64 UFS dirhash, allocindir, allocdirect, pagedep, NFS daemon, NFS req, in6_multi, fragment, routetbl, ether_multi, BPF, vnodes, cluster_save buffer, vfscache, pcb, iov, rman, mbufmgr, bus, sysctloid, sysctl, subproc, module, acpisem, ip6ndp, temp, devbuf, lockf, ithread, proc-args, file, acpica, isadev 128 ZONE, ppbusdev, UFS dirhash, freeblks, inodedep, NFS srvsock, fragment, ip_moptions, routetbl, vnodes, mount, vfscache, soname, ttys, iov, taskqueue, mbufmgr, eventhandler, bus, timecounter, cred, session, pgrp, module, ip6ndp, temp, devbuf, ithread, zombie, proc-args, acpica, pfs_nodes, DEVFS 256 UFS mount, UFS dirhash, newblk, NFS daemon, NFSV3 srvdesc, routetbl, ifaddr, vnodes, Export Host, vfscache, iov, bus, subproc, temp, devbuf, linker, proc-args, kqueue, file desc, dev_t, acpica 512 UFS dirhash, NFS daemon, NFSV3 diroff, routetbl, lo, ifaddr, mount, vfscache, BIO buffer, ptys, ttys, msg, iov, ioctlops, bus, ip6ndp, temp, devbuf, file desc, acpica 1K UFS dirhash, BIO buffer, sem, ioctlops, MD disk, bus, uidinfo, temp, devbuf, kqueue, acpica 2K UFS mount, UFS dirhash, ifaddr, BIO buffer, pcb, bus, temp, devbuf 4K memdesc, UFS mount, UFS dirhash, sem, msg, sbuf, kobj, bus, proc, temp, devbuf 8K UFS mount, UFS dirhash, indirdep, syncache, temp, DEVFS 16K shm, msg, devbuf 32K mbufmgr, temp, devbuf, pfs_fileno 64K temp 128K pagedep, mbufmgr 256K VM pgdata, UFS mount 512K UFS ihash, inodedep, NFS hash, vfscache, SWAP, ISOFS mount Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) atkbddev 2 1K 1K102400K 2 0 0 32 nexusdev 7 1K 1K102400K 7 0 0 16 memdesc 1 4K 4K102400K 1 0 0 4K ZONE 18 3K 3K102400K 18 0 0 128 VM pgdata 1 256K 256K102400K 1 0 0 256K ppbusdev 3 1K 1K102400K 3 0 0 128 UFS mount 18 176K 176K102400K 18 0 0 256,2K,4K,8K,256K UFS ihash 1 512K 512K102400K 1 0 0 512K UFS dirhash 4303 2138K 2356K102400K 53079 0 0 16,32,64,128,256,512,1K,2K,4K,8K newdirblk 2 1K 1K102400K 270 0 0 16 dirrem 0 0K 188K102400K 11739 0 0 32 mkdir 1 1K 1K102400K 620 0 0 32 diradd 139 5K 11K102400K 13744 0 0 32 freefile 1 1K 188K102400K 8913 0 0 32 freeblks 46 6K 752K102400K 67593 0 0 128 freefrag 8 1K 7K102400K 206189 0 0 32 allocindir 20 2K 176K102400K 99164 0 0 64 indirdep 7 1K 33K102400K 3317 0 0 32,8K allocdirect 243 16K 106K102400K 410504 0 0 64 bmsafemap 78 3K 10K102400K 46266 0 0 32 newblk 1 1K 1K102400K 509669 0 0 32,256 inodedep 249 543K 1265K102400K 82286 0 0 128,512K pagedep 7 129K 133K102400K 3165 0 0 64,128K p1003.1b 1 1K 1K102400K 1 0 0 16 NFS daemon 85 15K 15K102400K 85 0 0 64,256,512 NFSV3 srvdesc 1 1K 6K102400K 2598298 0 0 16,256 NFS srvsock 2 1K 1K102400K 2 0 0 128 NFS hash 1 512K 512K102400K 1 0 0 512K NFSV3 diroff 8 4K 4K102400K 14 0 0 512 NFS req 0 0K 2K102400K 191730 0 0 64 ip6_moptions 2 1K 1K102400K 6 0 0 16 in6_multi 8 1K 1K102400K 16 0 0 16,64 fragment 0 0K 1K102400K 132 0 0 64,128 syncache 1 8K 8K102400K 1 0 0 8K tseg_qent 0 0K 3K102400K 54453 0 0 32 ip_moptions 1 1K 1K102400K 3 0 0 128 in_multi 3 1K 1K102400K 4 0 0 32 igmp 1 1K 1K102400K 1 0 0 16 routetbl 295 41K 70K102400K 4851 0 0 16,32,64,128,256,512 lo 1 1K 1K102400K 1 0 0 512 ether_multi 38 2K 2K102400K 58 0 0 16,32,64 ifaddr 25 8K 8K102400K 25 0 0 32,256,512,2K BPF 4 1K 1K102400K 4 0 0 64 vnodes 27 7K 7K102400K 347 0 0 16,32,64,128,256 Export Host 42 11K 11K102400K 42 0 0 256 mount 17 9K 9K102400K 61 0 0 16,128,512 cluster_save buffer 0 0K 1K102400K 69898 0 0 32,64 vfscache435662 32388K 80389K102400K 13063992 0 0 64,128,256,512,512K BIO buffer 8 8K 2697K102400K 395143 0 0 512,1K,2K pcb 153 7K 14K102400K 80532 0 0 16,32,64,2K soname 22 2K 2K102400K 2000830 0 0 16,32,128 ptys 4 2K 2K102400K 4 0 0 512 ttys 566 75K 75K102400K 2477 0 0 128,512 shm 1 12K 12K102400K 1 0 0 16K sem 3 6K 6K102400K 3 0 0 1K,4K msg 4 25K 25K102400K 4 0 0 512,4K,16K iov 0 0K 1K102400K 182 0 0 64,128,256,512 ioctlops 0 0K 1K102400K 22 0 0 512,1K taskqueue 2 1K 1K102400K 2 0 0 128 sbuf 0 0K 5K102400K 2 0 0 32,4K rman 63 4K 4K102400K 410 0 0 16,64 mbufmgr 495 112K 116K102400K 7952262 0 0 16,32,64,128,32K,128K MD disk 1 1K 1K102400K 1 0 0 1K kobj 123 492K 492K102400K 123 0 0 4K eventhandler 29 2K 2K102400K 29 0 0 32,128 bus 697 50K 50K102400K 3770 0 0 16,32,64,128,256,512,1K,2K,4K SWAP 2 1097K 1097K102400K 2 0 0 32,512K timecounter 100 13K 13K102400K 100 0 0 128 sysctloid 46 2K 2K102400K 46 0 0 16,32,64 sysctl 0 0K 1K102400K 93864 0 0 16,32,64 uidinfo 9 2K 2K102400K 39 0 0 32,1K cred 101 13K 14K102400K 17629 0 0 128 subproc 167 15K 18K102400K 21046 0 0 64,256 proc 2 8K 8K102400K 2 0 0 4K session 46 6K 7K102400K 225 0 0 128 pgrp 51 7K 7K102400K 381 0 0 128 module 169 11K 11K102400K 169 0 0 64,128 acpisem 16 1K 1K102400K 16 0 0 64 ip6ndp 8 2K 2K102400K 12 0 0 16,64,128,512 temp 5 61K 98K102400K 289464 0 0 16,32,64,128,256,512,1K,2K,4K,8K,32K,64K devbuf 510 413K 413K102400K 1393 0 0 16,32,64,128,256,512,1K,2K,4K,16K,32K lockf 23 2K 2K102400K 20336 0 0 32,64 linker 34 2K 2K102400K 48 0 0 16,32,256 ithread 45 5K 5K102400K 45 0 0 64,128 atexit 2 1K 1K102400K 2 0 0 16 zombie 0 0K 2K102400K 20697 0 0 128 proc-args 98 6K 9K102400K 21587 0 0 16,32,64,128,256 kqueue 5 5K 6K102400K 35 0 0 256,1K sigio 1 1K 1K102400K 2 0 0 32 file 376 24K 28K102400K 3582335 0 0 64 file desc 146 37K 47K102400K 21496 0 0 256,512 dev_t 1477 370K 370K102400K 1477 0 0 256 acpica 2169 112K 112K102400K 10086 0 0 16,32,64,128,256,512,1K acpidev 100 2K 2K102400K 100 0 0 16 ISOFS mount 1 512K 512K102400K 1 0 0 512K isadev 28 2K 2K102400K 28 0 0 64 pfs_vncache 0 0K 1K102400K 6 0 0 32 pfs_fileno 1 20K 20K102400K 1 0 0 32K pfs_nodes 20 3K 3K102400K 20 0 0 128 DEVFS 149 25K 25K102400K 149 0 0 16,128,8K Memory Totals: In Use Free Requests 40350K 80500K 32039231 ITEM SIZE LIMIT USED FREE REQUESTS SWAPMETA: 160, 509724, 70, 749, 784 ripcb: 192, 8232, 3, 39, 13 syncache: 160, 15359, 0, 51, 96702 tcpcb: 544, 8232, 383, 1273, 175720 udpcb: 192, 8232, 72, 34, 1905 unpcb: 160, 0, 44, 31, 495 socket: 224, 8232, 503, 1289, 178141 KNOTE: 64, 0, 0, 128, 22 DIRHASH: 1024, 0, 491, 1493, 133876 PIPE: 192, 0, 39, 131, 6172 NFSNODE: 320, 0, 1258, 1490, 13343 NFSMOUNT: 256, 0, 7, 25, 49 FFSNODE: 256, 0, 412703, 1457, 12363841 NAMEI: 1024, 0, 0, 32, 35173731 VNODEPOLL: 64, 0, 0, 320, 1 VNODE: 224, 0, 414318, 96, 414318 VMSPACE: 224, 0, 107, 55, 20788 PROC: 768, 0, 144, 64, 20841 DP fakepg: 64, 0, 0, 0, 0 PV ENTRY: 28, 2396042, 163256, 623165, 11586363 MAP ENTRY: 48, 0, 3108, 760, 6306679 KMAP ENTRY: 48, 193110, 477, 163, 55810 MAP: 108, 0, 8, 39, 8 VM OBJECT: 96, 0, 186835, 223803, 1774809 --Multipart_Sun_Mar__3_21:41:18_2002-1 Content-Type: text/plain; charset=US-ASCII -- Seigo Tanimura --Multipart_Sun_Mar__3_21:41:18_2002-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 3 4:56:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 442B537B400; Sun, 3 Mar 2002 04:56:02 -0800 (PST) Received: from localhost (root@tasogare.imasy.or.jp [202.227.24.5]) by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare) with ESMTP/inet id g23CtxP93169; Sun, 3 Mar 2002 21:56:00 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sun, 03 Mar 2002 21:55:52 +0900 (JST) Message-Id: <20020303.215552.112630160.iwasaki@jp.FreeBSD.org> To: msmith@freebsd.org Cc: arch@freebsd.org Subject: Re: CFR: Generalized power profile From: Mitsuru IWASAKI In-Reply-To: <200112281839.fBSIdGF13050@mass.dis.org> References: <20011227.182533.112880512.iwasaki@jp.FreeBSD.org> <200112281839.fBSIdGF13050@mass.dis.org> X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Sorry for too late reply. It seems that I've woken up from hibernation.] From: Mike Smith Subject: Re: CFR: Generalized power profile Date: Fri, 28 Dec 2001 10:39:16 -0800 Message-ID: <200112281839.fBSIdGF13050@mass.dis.org> > > I've made the changes for generalized power profile based on ACPI > > power profile code, dev/acpica/acpi_powerprofile.c and some related > > files. This makes other power-management system (APM for now) to be > > able to generate power profile change events (ie. AC-line status > > changes), and other kernel components, not only the ACPI components, > > can be notified the events. > > Thanks for picking up on this. > > > This includes: > > - move subroutines in acpi_powerprofile.c to kern/subr_power.c > > If we think this might become more complicated, do we want sys/dev/power? > If not, this is an OK place. Maybe not I guess, I'll put them into kern/subr_power.c for now. > What do you think of POWER_PROFILE_OFF as an alternate mechanism for > switching the system off, rather than the current shutdown hook? I'm not sure whether power profile change event should include power off event too or not, but I updated the diffs a bit adding sanity check code. http://people.freebsd.org/~iwasaki/acpi/power_profile-20020303.diff I'll commit this in a day or two. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 3 12: 1:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4170337B405 for ; Sun, 3 Mar 2002 12:01:36 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g23Jwwm63106; Sun, 3 Mar 2002 11:58:58 -0800 (PST) (envelope-from dillon) Date: Sun, 3 Mar 2002 11:58:58 -0800 (PST) From: Matthew Dillon Message-Id: <200203031958.g23Jwwm63106@apollo.backplane.com> To: Seigo Tanimura Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: reclaiming v_data of free vnodes References: <200202231556.g1NFu9N9040749@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <200202242041.g1OKfXt95731@apollo.backplane.com> <200202250325.g1P3PVN9092431@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <200202250444.g1P4i8X29005@apollo.backplane.com> <200202251437.g1PEb12R001419@bunko> <3C7A5D24.E11A6693@mindspring.com> <200202251754.g1PHsTs50126@apollo.backplane.com> <200202260923.g1Q9NkVh093544@rina.r.dl.itc.u-tokyo.ac.jp> <200203031242.g23CfIfu059069@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Seigo, could you hold onto this patch for a while? I have too many things on my plate, including some unsettling filesystem related issues which hopefully Kris will be able to pinpoint in the next few days. Tor also has some O_DIRECT patches from Feb 24th or so and, of course, the SMPng crap is like a thorn stuck in a bleeding ulcer (hey Core! I want to commit that!). -Matt Matthew Dillon :--Multipart_Sun_Mar__3_21:41:18_2002-1 :Content-Type: text/plain; charset=US-ASCII : :Attached is the patch to use the zone allocator for in-core inodes. : :On Tue, 26 Feb 2002 18:23:45 +0900, : Seigo Tanimura said: : :Seigo> AFAIK, all of ffs, ifs and ext2fs utilize struct inode and :Seigo> dinode. They deal with the filesystem-specific data by a union. All of :Seigo> the filesystems should thus be able to share a single zone. : :However, the usage of a few of the members (eg i_spare) depends on the :filesystem. So I actually gave a distinct zone for each of ffs, ifs :and ext2fs. This also gives the better modularity of the filesystem :than a single zone. : :The patch includes the following optimization to the initialization of :a new in-core inode as well: : : - Do not clear the members filled in *_vget(). : - Since NODQUOT is defined as NULL, clear i_dquot only in : ufs_reclaim(). : :Finally, the result of vmstat -mz on cvsup.jp.FreeBSD.org follows the :patch. At that time, the host was up for a few hours, during which I :took du(1) over the whole cvsup tree. : : :--Multipart_Sun_Mar__3_21:41:18_2002-1 :Content-Type: application/octet-stream; type=gzip :Content-Disposition: attachment; filename="inodezone2.diff.gz" :Content-Transfer-Encoding: base64 : :H4sIAK0SgjwCA+08aXPbOJaf6V+BTlelJEuydcvHpLdTHXvGu4ndEzu9mZ3qYlEiaGNCkWwe :Spxs9rfvew8gCVKkROWoxLvtRBIJ4OF4F94B0haOw3pJeMkODg6dkPN5ZB9G99Hhwrct+jJX :TuQH0cGCHVQU7vV6ve2gxs1dws75nA2P2GB2MpmdDIZs2O8P9zqdTmW/6xDDYwnx88+sN+kP :u1PWwZ9j9vPPe8wwGP1dvnr+vEvf7dM99nGP7XV+FN7CTWzO/rJaHq6WB3c/rZWZ732PU8Ue :y6sSJzrED38XW3EcYn1F7R+JH1s1dfBZ+okXY7Vdj+hlYMWHrvCSd/LbdITLFb5r6qrRXtN4 :O/YbA+pEGE+RBvAtSZAvHycTx/clpGDpyvNtQvQDoMutl+AQQznS0LRc118QVWpqqmhS09S4 :STi75gEbTtjg+GQ0PRn3EbEDRZFasDI9RiNdKKRMVNIjW2+pHD6uf/vtSSJSzmhMj3k9QeY7 :UGT+iSSZN6LJ+Ihk5KiSJski5PbXlpJGSK+WERMWykNvJ6qkIBUYS6uaUCVtuytVcrhNVBn0 :x90x6+DPlOgiwdjKD8yY7e9TV1HAF3AfnFZXO8LxVfVeJ20gaQGNsAkil+5PiTLcAySyw332 :g3n9j2vzr5evzLPXN8Pza/rBr7OXl+bfTLZ/2BzdkoJVMqBqmiBbNd0V1xnYRqU0IqU06s4I :0TqnZQxdLtP4rpbX2WeoH5zXbIDzmg3VvIQXE5lxVSJuRXGYLGIGxsjC9xy2DxdBe4992OsY :BcqyJ+w9ATySpLy8enb2qMsi8Z77TtoL4andZX36P0HDxAh5nADDtFDKqAMaIbVZdiO/ufBW :9SwgaxuzgWxewQqDrayQgm5ihxGhHb6r9GEE1Ps+1GFzCkhzacNeVGzQhA5FiF1JUYbeSI0J :UWOyk8XwkG04iRyxjVpiZ2qJz6KWaEYtsrdH04dIrd3NO9f33yRBNZFUVSPyqLY7EyaD27i7 :EUkmNSSRVF2niS1Croj1wIgSJfOwkiSyoglBZMtdyZFCfbL/8x3Z2s3RrUVe6qqaoHxDFGaq :xwFq4a6tmL2wQsaGbDg46c9O+n0N7eTiTI522dKXSczffV97CC7laAzmYOdopoxCnLxYoG0o :TcPVLY+Zaf7aSi07Amb7XTTxzBjsPmU2IqnBTyB7bq2TIPadu0I3qn0G7wibSeC9ngJ/8fT5 :86tfzGdn5xeXZ60X5DKgsdllZHky7OFReiP7C0KxsmL4tcL4EXTWqfVOWDbL3O4FwjPJC4oN :wNT9AIYrrYHW3SWUTY8miLPp0ZFCmgEGrJEsA2gP/GhKJdiSFjHbh4oue2G+Or9+cXmDV//5 :9OLm6j/IJp6/56Hfai0s2w7NuE1NNTho08OOez8lS9VtfB+gCZ6jA1aZNVH2eXmtWf3cfWMB :KRzVJrvX2wA6vAUiUbVJ7/U2SWBrLeTdqXIzh7PuYISO5qiPF4QfhVVpMt9Z0R3sNYs3AD8g :ShiH+7BOts8uHBbfiUiRvtVmcB3w0PHDJbeZ5YCLBA04A6b0+FuieasN69dA30vkNwRlCCqA :q8XtXczmOKsuc7m1Et4tsxRXvRXxHdxghJWtTFirxWKfzbmEdoAxbDa/l7iI7j0a3AEAvGZ3 :VhBwL0IIB/ZAFtJIMBOvK+Hf3onFHYzhumxhJREHwMDygDHnXN7r/c7BeLLdewlp85A78PEW :PGIroIyaXMuK2FsO/cHCojs/ce32AUEcApYVakWQiZ7IRLHShdMFT+PdjiGQ31vFTtoK/QUO :bKdEZk+xEjnHYkAEiV61S+DsmAF4a7V4GPoh9K2T6rcbFKAuQwGROgWLMRjRZY9X4EayH56w :fhvkVQU7Bt1hn8Id4+4gjZcbb603PAlaj6v5kSSynlf7VL2/CnDdyAwonMb5y7MzwmaOJ8KO :8R63pyIiQGkGcpDUF6alUtFH6KykDURQTRPs/0ebOwKE/eXTy7+eXZ23UC0gRUHxAYI8u81a :INcRB+lWdVTYY6VSgmijDJUGfyyAoYRJ9VjTRTGDv1biReLW49BZOrY+OViiBgM3MCxeykmD :pHAnhYNFI2YpFPBYsq+Uv18vAIug2BF3wnskowiEJI3JnwAusUhOUwrqE5CCvIwDGaGIvlLF :hWV5C5uvoA6+8yIvWc45Mh+sBuj7IzDk319d3TwF6oAqYS1BjMAE+wsoqddUdQ23nU4bmUF1 :i/vvP8XvyCZXz7AN9kSxMKnrSHp/TWIUUN8DzSDiiCGrscWdJTxmgUIhpkMB9kFZgC3ig8oI :Wcj/SHgErWEyshtSekLpKZD5uQREbcjvmRXCjshRx7jwDXIHGihyOQ9Qv721RAy/O9hmXq1p :5jW3zDxlmK1Zw8NN1nAGtmYOj3O7bIrBzc50/MUjb8UKEujAuuXhWliODECQD8tdWeFGPwON :MUd+tDxLRWkVUiuaGeehIMywIzYcAlpORjPd0q0CWUPmWEPm+Jji+MfVRu59tIjdB51c0REy :r6bAvCEJ5tU0GI5OJkd1NJg3IwIlfcfDbxcA+crJFB0lWiKlqngbFbJEyA5UqE+e6FSYDboD :sCbkj4qdGwguIqlvddcGNhwwphITdHlIV9DOVrsq7mI5LC2kDl5ts2xbN8QEALPJu8qcNnUf :34XcAoeri2Y3/qXtiCdN8jHIG5N7fp7kWR859H3lIK58YWN9r1Bf7Tymi1LWRjYxz1pyQft7 :NrfSlGlW6Qi2/7ljdKrG6NYsGGoRP+A1ldANdqhWZ1rhbaS82RLo4rYAmJreuJXDn0bibvEG :ulFfCpJiOxpF54mjvO9Gkpbn0CpKt8lZmgTbQcxq82a6lGXBrO8ob9YIm5FnBeBoxWsIzSu2 :4TRvWXEApXYf3wRV2EU2peRDHvlJuODKYHnAqY8CanwntnmwTpK0fCtF0oYVBKnl8w1AOj2m :lBKcZttJrQlVR4tiOSZsJc4/n0S2qCPPF5WYNKi+XriVLpXB9GMlJYMqotQE0hsbu6BcK7Ce :h9e/kZVVtmEa4l6LsFcVb8P/htOKtWKxIaquJzPkAcdhtVTUppZ2Dayj4/YtI+4o9hOQ/kl3 :MC6tM8NZ1IjcDAMUawvu1S24VxtaP5fHOLrsEVxlgXW8romrq37y8DpMrDK6nto/0VzFjHXz :J8WMTCeUbS3XB1usyrIrmUAVBmJ5dN+18VgLHvlcM7Wr2mNMqmjhpadi2trqMb9Bf7mxu9UI :xcigZnHqtuiapVufpUjKKYpsBjJDMRgNZBB+NO6CVCKTsX3DAGmJ+RLm4royWORYwpXh7bPz :p6+e38CS2MIP7oUH48GNBKNJyqA2oEVEzGK33Esw/EgxcSf0lxRbTyIeHiDMITkBOqL2ciS1 :MIYLlLjrMlx5l3k2FMR2e6/D1J+ORcPYXwaneR1i1IBC7EEvlgiGGuz0dK2vDNPGPoy3Xi+x :Dv3GNlTiqac0Rqs5GnVT7xb4n3jkI+7Gh/swzj77xV8ufcQsiBJGEaExxfgEyDk2OCSPZq/T :aCQaYY/VowoD7ZL/VF3gQ+88xAB7JRIRAC8wRyEBCaLQvohdhAAnJ1lyL6bUBmgKPDsoHKA2 :daEDV1MgnyaNxlCaoTthuVEFsE4emm/oL3gUpQFRDGem42aUzbSTYZBaQjjKkPkO6TgaB6UH :g+zYCn8xFKx70ca+zVcYVia5mkwx8zeYpRFGoyqUj+lAigbryQzNVW+hz7wKZDIDSZop4DSN :gVqiMXSR9VQHlTPDUumm/3Z+bV7fPL05vyZGe4zh8aUXY+g+JlmU6x2N8RBjZwRbVrpeCjnz :AuVAI9giWlihzSkRRqogCHjIXL7iLvH9gYK99GEPoID2KtMHbegnSFzYHSLmmDAN30NeIVFJ :IgV5uBGjRKMNCKVjjI3BdUwSgxjGCvYjLttJGlfTXR7/nHYHAzBkJmP8lcp3TQdIBKIWyMIo :UnOStuxtmF2eB25LlbFpFXTu8lZEmP4sBocUW2fcrraspV6WbkWoE3tGVZAonwwGi3J7QNkB :HyrGz3f9pDAYhTDmStKmkwHl2KfHGefd+qBo/CQ+LSTcmyXb2X/D5X+dvbyqz6gXV1LKqJcT :6cLkjuO5wntjrixX2CqVndVT0klNrZWYru/dtp2o9xNZQjhXbZIq+KPlVknVDKZDNBA7g8FR :nkhfxu/MxMOQYeuxU8xSQlX7/1A2nYzGL59M17r9Brl0FdJc578dUusFdd88s74tqU5uWjGn :njLi0ZSi34Nhf5QxIunStxZsGTKn3i7k15265Hpt9nwdJXoWXV/zn0n0UhI9TSijuxbBvuuH :YJNRViECKw9FD6x6FFboEgpBSxKdI8XGRGPwwaXDMBz21fMhKpm9nkPfOYOO002T6B9oG0ej :gejfIKe+KamOBP+OE+vSFRvT4yCDEdmOMrBtqDghOZpg8QJ/toiBUb/LAxHr2h08cnAYVrcx :+OYvbl6j904yogtH/nDG+dd/MqMQ4fEqY0pes5BS9ZGAYxVRqorp1R4HKCQU6Kz/ZKLwXhcX :Wavw5//ii/i7SzcI+dGPiVcV12G73K4Jutdh1vA9qQiiPpQETrq8Uki0XLwNo4WQ6DO+YMMZ :YnQ8OxlN6jDaMCRKiYJJ9bND4HS9ca05rzqGoUVLv6vjxtMR2RLTaeoaNWOSrTFbRv/q4psX :WXzzQotvXuwQ3xQb4psijRiuRwtP1xo2jRNK06tP4YZBGm74II29X8Cmlva32keY41q30s5L :PXkqefyE/Q+4GOb11fnNs7NfccfUo1qbw3G0uewUBBOlIBhtH0wuZTyjXXCSRRKqnjdUHmO+ :C4rGu6Co3AUvvtguSIs4OpYu2fG40iMTf3pk/x89MvF1PDJR55ENB1KJDgezhv6Y+ML+mPjT :H9vuj118uj82VA9RDEfjP72xr37MuZRnV4aaVlJn/2lNKozp47LppzffaPVNZ93hAIykTLxJ :YRSUD26Tzy+ub8yzy5uX/2hJGQLORPSegvb5W4Zm0jaUi2I3dxh7BoF+S/kSjqwREbIWaFHA :PgJU+QCy1AUB7+Kx64/0AFirLTtR8mlo0mDIIdFsNG6eXjz/e3lCHnSDx5RO8TUQ6Xklhu/a :Ya6IYqm25dIMuR2xfXWeH9fxGxVZUeQvBChTW25WOTcc1HQgo9tZB8jZkmUuDq+U/k1AJcaj :IRp3ZC1RfggvItAgnMMGBYiS3UNvZgyagvqlds/4SiyqJsYL86KH5AhQCiLBIhkE5briexT/ :IhBDgSSQNMRMQNADXgOPcw8XwTCd7XLMmeBIGNX2hA/kAxnF3SefGOJaZn7VpFJsYfYb1Ae1 :x+BRoVI+dTQHHDk+26fnJrCdfOeDbPpRztpMULFkrOFEhio+cCK9AvvIqvAmpxsjfUJ0I8WS :KZ7fiW2eUa1sm4Q8ygj4R2LZRL+lb4eKMi+BMhFiQiafkPKXMGNg8ChFcDoqMoSDo9IFiQ2m :O4Ak8/uY92QHxDXIqgoYFBvK6DE9Bn101B0OpYLW2SkCR4L/c/Q7Tej169fMgonDTnoPvofX :o1owqWFm8gkHKV4sN4ptEZKeRITIS8IDCjVKLkK6VnjLsSFfxH4oJBtIMX+hBDsJ0CwDfSoV :IorrDiKu9jhDCSP2/bly2vkEOe18qvB1PkX4cJEN5aizSY46zeWoo8tRp06OOpvkqPN5cpRu :1YgaYE8MKwBjET1gx+auk9rXW3dQdJ2shZsFUgplm3bRrBHtoxhgGhyzwdHJCPbGaflUWQlg :Y0SKIoDj6rd9gHhXPj6hRzu+4QMUuLxtAawUFfOlFaxhXRZuQ7ts1dR+0SEahQJ3P3GcPT// :AJ4fSlFSPE9fKt1GAf08/b9bHvA9kmBQdZ6+DPLpNPhixym/Nv4p8DJT526y0wDo7ipXRO2V :P0g3lhxf6EAVm9JfJQ9V+SY96eXmIYUu++38+uYKHG9VSGGudpX/K93f+ubSIc67Xn9qta+H :mvoyutSIxUpR/3LxNiarj+APa7msWdQ/eyHMQ4n6p8uTrcsIVaXb8Kma7YLOWpACNje90QVs :kTf8Qb/ySMdHKetSLt5GgV0Oom+HKdBgU9blwdAgf1FNdnxv21OaIHLl1El6kuoRXMh0xSP9 :JrcmKW+yx9CYBFvyhfUGI5+5zcz8gIdWDKa15dIZYTwKSN4M+Ci2z6xYnSvEM6UHDRnIq+Qf :rxn7aEnnosE5q+UerwHzTCnRMZ19VXWIWXDh+OpnyyuW1nNxxXWpwi0IU63WDcVRv8ZQzCA2 :oUu9fyg7UBuLJZ7FxTN2eKm7MORgSb+EBIBhA3DNlyKWjgydagbIPyiKswYqgbJzytQoi7hM :x3LUyFpxe2m9I87F88BG6sP31FBapR58Kp6LLJgOueNJgV7tqKF0APODysqEkINqEJTVyoJD :FQcQFXKyUkal/5bDtHBK8pnzdvWzwr7jmHVPmeqF+aOmes/qTUKb+5ZZzqqnVv8XcjwYJpRd :AAA= : :--Multipart_Sun_Mar__3_21:41:18_2002-1 :Content-Type: text/plain; charset=US-ASCII : : : :--Multipart_Sun_Mar__3_21:41:18_2002-1 :Content-Type: text/plain; charset=US-ASCII :Content-Disposition: inline; filename="vmstat-mz.inodezone.txt" :Content-Transfer-Encoding: 7bit : :Memory statistics by bucket size :Size In Use Free Requests HighWater Couldfree : 16 1147 1413 11388727 1280 9391 : 32 1795 5885 1049592 640 1668 : 64 377911 63561 14943019 320 176 : 128 59718 51130 1628292 160 17048 : 256 3945 38407 1457347 80 94181 : 512 4643 114285 1167114 40 47681 : 1K 93 2615 389590 20 195559 : 2K 19 263 11722 10 8816 : 4K 150 3 2074 5 0 : 8K 4 4 1695 5 0 : 16K 15 0 15 5 0 : 32K 3 0 9 5 0 : 64K 1 0 1 5 0 :128K 2 0 2 5 0 :256K 2 0 2 5 0 :512K 6 0 6 5 0 : :Memory usage type by bucket size :Size Type(s) : 16 nexusdev, UFS dirhash, newdirblk, p1003.1b, NFSV3 srvdesc, : ip6_moptions, in6_multi, igmp, routetbl, ether_multi, vnodes, mount, : pcb, soname, rman, mbufmgr, bus, sysctloid, sysctl, ip6ndp, temp, : devbuf, linker, atexit, proc-args, acpica, acpidev, DEVFS : 32 atkbddev, UFS dirhash, dirrem, mkdir, diradd, freefile, freefrag, : indirdep, bmsafemap, newblk, tseg_qent, in_multi, routetbl, : ether_multi, ifaddr, vnodes, cluster_save buffer, pcb, soname, sbuf, : mbufmgr, eventhandler, bus, SWAP, sysctloid, sysctl, uidinfo, temp, : devbuf, lockf, linker, proc-args, sigio, acpica, pfs_vncache : 64 UFS dirhash, allocindir, allocdirect, pagedep, NFS daemon, NFS req, : in6_multi, fragment, routetbl, ether_multi, BPF, vnodes, : cluster_save buffer, vfscache, pcb, iov, rman, mbufmgr, bus, : sysctloid, sysctl, subproc, module, acpisem, ip6ndp, temp, devbuf, : lockf, ithread, proc-args, file, acpica, isadev : 128 ZONE, ppbusdev, UFS dirhash, freeblks, inodedep, NFS srvsock, : fragment, ip_moptions, routetbl, vnodes, mount, vfscache, soname, : ttys, iov, taskqueue, mbufmgr, eventhandler, bus, timecounter, cred, : session, pgrp, module, ip6ndp, temp, devbuf, ithread, zombie, : proc-args, acpica, pfs_nodes, DEVFS : 256 UFS mount, UFS dirhash, newblk, NFS daemon, NFSV3 srvdesc, routetbl, : ifaddr, vnodes, Export Host, vfscache, iov, bus, subproc, temp, : devbuf, linker, proc-args, kqueue, file desc, dev_t, acpica : 512 UFS dirhash, NFS daemon, NFSV3 diroff, routetbl, lo, ifaddr, mount, : vfscache, BIO buffer, ptys, ttys, msg, iov, ioctlops, bus, ip6ndp, : temp, devbuf, file desc, acpica : 1K UFS dirhash, BIO buffer, sem, ioctlops, MD disk, bus, uidinfo, temp, : devbuf, kqueue, acpica : 2K UFS mount, UFS dirhash, ifaddr, BIO buffer, pcb, bus, temp, devbuf : 4K memdesc, UFS mount, UFS dirhash, sem, msg, sbuf, kobj, bus, proc, : temp, devbuf : 8K UFS mount, UFS dirhash, indirdep, syncache, temp, DEVFS : 16K shm, msg, devbuf : 32K mbufmgr, temp, devbuf, pfs_fileno : 64K temp :128K pagedep, mbufmgr :256K VM pgdata, UFS mount :512K UFS ihash, inodedep, NFS hash, vfscache, SWAP, ISOFS mount : :Memory statistics by type Type Kern : Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) : atkbddev 2 1K 1K102400K 2 0 0 32 : nexusdev 7 1K 1K102400K 7 0 0 16 : memdesc 1 4K 4K102400K 1 0 0 4K : ZONE 18 3K 3K102400K 18 0 0 128 : VM pgdata 1 256K 256K102400K 1 0 0 256K : ppbusdev 3 1K 1K102400K 3 0 0 128 : UFS mount 18 176K 176K102400K 18 0 0 256,2K,4K,8K,256K : UFS ihash 1 512K 512K102400K 1 0 0 512K : UFS dirhash 4303 2138K 2356K102400K 53079 0 0 16,32,64,128,256,512,1K,2K,4K,8K : newdirblk 2 1K 1K102400K 270 0 0 16 : dirrem 0 0K 188K102400K 11739 0 0 32 : mkdir 1 1K 1K102400K 620 0 0 32 : diradd 139 5K 11K102400K 13744 0 0 32 : freefile 1 1K 188K102400K 8913 0 0 32 : freeblks 46 6K 752K102400K 67593 0 0 128 : freefrag 8 1K 7K102400K 206189 0 0 32 : allocindir 20 2K 176K102400K 99164 0 0 64 : indirdep 7 1K 33K102400K 3317 0 0 32,8K : allocdirect 243 16K 106K102400K 410504 0 0 64 : bmsafemap 78 3K 10K102400K 46266 0 0 32 : newblk 1 1K 1K102400K 509669 0 0 32,256 : inodedep 249 543K 1265K102400K 82286 0 0 128,512K : pagedep 7 129K 133K102400K 3165 0 0 64,128K : p1003.1b 1 1K 1K102400K 1 0 0 16 : NFS daemon 85 15K 15K102400K 85 0 0 64,256,512 :NFSV3 srvdesc 1 1K 6K102400K 2598298 0 0 16,256 : NFS srvsock 2 1K 1K102400K 2 0 0 128 : NFS hash 1 512K 512K102400K 1 0 0 512K : NFSV3 diroff 8 4K 4K102400K 14 0 0 512 : NFS req 0 0K 2K102400K 191730 0 0 64 : ip6_moptions 2 1K 1K102400K 6 0 0 16 : in6_multi 8 1K 1K102400K 16 0 0 16,64 : fragment 0 0K 1K102400K 132 0 0 64,128 : syncache 1 8K 8K102400K 1 0 0 8K : tseg_qent 0 0K 3K102400K 54453 0 0 32 : ip_moptions 1 1K 1K102400K 3 0 0 128 : in_multi 3 1K 1K102400K 4 0 0 32 : igmp 1 1K 1K102400K 1 0 0 16 : routetbl 295 41K 70K102400K 4851 0 0 16,32,64,128,256,512 : lo 1 1K 1K102400K 1 0 0 512 : ether_multi 38 2K 2K102400K 58 0 0 16,32,64 : ifaddr 25 8K 8K102400K 25 0 0 32,256,512,2K : BPF 4 1K 1K102400K 4 0 0 64 : vnodes 27 7K 7K102400K 347 0 0 16,32,64,128,256 : Export Host 42 11K 11K102400K 42 0 0 256 : mount 17 9K 9K102400K 61 0 0 16,128,512 :cluster_save buffer 0 0K 1K102400K 69898 0 0 32,64 : vfscache435662 32388K 80389K102400K 13063992 0 0 64,128,256,512,512K : BIO buffer 8 8K 2697K102400K 395143 0 0 512,1K,2K : pcb 153 7K 14K102400K 80532 0 0 16,32,64,2K : soname 22 2K 2K102400K 2000830 0 0 16,32,128 : ptys 4 2K 2K102400K 4 0 0 512 : ttys 566 75K 75K102400K 2477 0 0 128,512 : shm 1 12K 12K102400K 1 0 0 16K : sem 3 6K 6K102400K 3 0 0 1K,4K : msg 4 25K 25K102400K 4 0 0 512,4K,16K : iov 0 0K 1K102400K 182 0 0 64,128,256,512 : ioctlops 0 0K 1K102400K 22 0 0 512,1K : taskqueue 2 1K 1K102400K 2 0 0 128 : sbuf 0 0K 5K102400K 2 0 0 32,4K : rman 63 4K 4K102400K 410 0 0 16,64 : mbufmgr 495 112K 116K102400K 7952262 0 0 16,32,64,128,32K,128K : MD disk 1 1K 1K102400K 1 0 0 1K : kobj 123 492K 492K102400K 123 0 0 4K : eventhandler 29 2K 2K102400K 29 0 0 32,128 : bus 697 50K 50K102400K 3770 0 0 16,32,64,128,256,512,1K,2K,4K : SWAP 2 1097K 1097K102400K 2 0 0 32,512K : timecounter 100 13K 13K102400K 100 0 0 128 : sysctloid 46 2K 2K102400K 46 0 0 16,32,64 : sysctl 0 0K 1K102400K 93864 0 0 16,32,64 : uidinfo 9 2K 2K102400K 39 0 0 32,1K : cred 101 13K 14K102400K 17629 0 0 128 : subproc 167 15K 18K102400K 21046 0 0 64,256 : proc 2 8K 8K102400K 2 0 0 4K : session 46 6K 7K102400K 225 0 0 128 : pgrp 51 7K 7K102400K 381 0 0 128 : module 169 11K 11K102400K 169 0 0 64,128 : acpisem 16 1K 1K102400K 16 0 0 64 : ip6ndp 8 2K 2K102400K 12 0 0 16,64,128,512 : temp 5 61K 98K102400K 289464 0 0 16,32,64,128,256,512,1K,2K,4K,8K,32K,64K : devbuf 510 413K 413K102400K 1393 0 0 16,32,64,128,256,512,1K,2K,4K,16K,32K : lockf 23 2K 2K102400K 20336 0 0 32,64 : linker 34 2K 2K102400K 48 0 0 16,32,256 : ithread 45 5K 5K102400K 45 0 0 64,128 : atexit 2 1K 1K102400K 2 0 0 16 : zombie 0 0K 2K102400K 20697 0 0 128 : proc-args 98 6K 9K102400K 21587 0 0 16,32,64,128,256 : kqueue 5 5K 6K102400K 35 0 0 256,1K : sigio 1 1K 1K102400K 2 0 0 32 : file 376 24K 28K102400K 3582335 0 0 64 : file desc 146 37K 47K102400K 21496 0 0 256,512 : dev_t 1477 370K 370K102400K 1477 0 0 256 : acpica 2169 112K 112K102400K 10086 0 0 16,32,64,128,256,512,1K : acpidev 100 2K 2K102400K 100 0 0 16 : ISOFS mount 1 512K 512K102400K 1 0 0 512K : isadev 28 2K 2K102400K 28 0 0 64 : pfs_vncache 0 0K 1K102400K 6 0 0 32 : pfs_fileno 1 20K 20K102400K 1 0 0 32K : pfs_nodes 20 3K 3K102400K 20 0 0 128 : DEVFS 149 25K 25K102400K 149 0 0 16,128,8K : :Memory Totals: In Use Free Requests : 40350K 80500K 32039231 : :ITEM SIZE LIMIT USED FREE REQUESTS : :SWAPMETA: 160, 509724, 70, 749, 784 :ripcb: 192, 8232, 3, 39, 13 :syncache: 160, 15359, 0, 51, 96702 :tcpcb: 544, 8232, 383, 1273, 175720 :udpcb: 192, 8232, 72, 34, 1905 :unpcb: 160, 0, 44, 31, 495 :socket: 224, 8232, 503, 1289, 178141 :KNOTE: 64, 0, 0, 128, 22 :DIRHASH: 1024, 0, 491, 1493, 133876 :PIPE: 192, 0, 39, 131, 6172 :NFSNODE: 320, 0, 1258, 1490, 13343 :NFSMOUNT: 256, 0, 7, 25, 49 :FFSNODE: 256, 0, 412703, 1457, 12363841 :NAMEI: 1024, 0, 0, 32, 35173731 :VNODEPOLL: 64, 0, 0, 320, 1 :VNODE: 224, 0, 414318, 96, 414318 :VMSPACE: 224, 0, 107, 55, 20788 :PROC: 768, 0, 144, 64, 20841 :DP fakepg: 64, 0, 0, 0, 0 :PV ENTRY: 28, 2396042, 163256, 623165, 11586363 :MAP ENTRY: 48, 0, 3108, 760, 6306679 :KMAP ENTRY: 48, 193110, 477, 163, 55810 :MAP: 108, 0, 8, 39, 8 :VM OBJECT: 96, 0, 186835, 223803, 1774809 : : : :--Multipart_Sun_Mar__3_21:41:18_2002-1 :Content-Type: text/plain; charset=US-ASCII : : :-- :Seigo Tanimura : :--Multipart_Sun_Mar__3_21:41:18_2002-1-- : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-arch" in the body of the message : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 3 12:43:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 2F3D037B402 for ; Sun, 3 Mar 2002 12:43:38 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020303204332.KUBS1214.rwcrmhc54.attbi.com@gateway.posi.net>; Sun, 3 Mar 2002 20:43:32 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g23KhU621433; Sun, 3 Mar 2002 12:43:30 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Sun, 3 Mar 2002 12:43:29 -0800 (PST) From: Kelly Yancey To: Matthew Dillon Cc: Alfred Perlstein , Jeff Roberson , Poul-Henning Kamp , Julian Elischer , Subject: Re: Slab allocator update In-Reply-To: <200203021815.g22IF0e55311@apollo.backplane.com> Message-ID: <20020303120514.W21325-100000@gateway.posi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 2 Mar 2002, Matthew Dillon wrote: > :I think that the overhead and inconvience to store the size of the > :allocations may be too much for us to deal with. > > I have to disagree here. I have a lot of experience converting > malloc()/free() based systems to other types of memory allocators > where the 'free' requires a size. It's utterly trivial. The size > is known trivially in 99% of the cases. > As someone who has used one of Matt's other allocators in which free() requires a size, I have to agree with him. Adding a size parameter to free offloads the management of the size information from the software to the programmer. While it may not be ideal for general purpose software, it makes very good sense when you are looking to optimize software for speed. Kelly kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 3 21: 0:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 27ED237B419 for ; Sun, 3 Mar 2002 21:00:15 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id UAA70437; Sun, 3 Mar 2002 20:56:13 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g244tr429559; Sun, 3 Mar 2002 20:55:53 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203040455.g244tr429559@arch20m.dellroad.org> Subject: Re: Patches to if_loop + the interface cloning framework In-Reply-To: "from Julian Elischer at Mar 1, 2002 11:24:16 am" To: Julian Elischer Date: Sun, 3 Mar 2002 20:55:53 -0800 (PST) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer writes: > I think loopback is not really 'optional' and should come as soon > as you have any networking at all. Why? From a theoretical standpoint, there's nothing mandatory about it. E.g., consider a machine that is only a router, has no users, etc. It doesn't need one. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 7: 7:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nimbus.nj.caldera.com (nimbus.nj.caldera.com [132.147.103.56]) by hub.freebsd.org (Postfix) with ESMTP id E673C37B400 for ; Mon, 4 Mar 2002 07:07:01 -0800 (PST) Received: from caldera.com (bird [132.147.135.198]) by nimbus.nj.caldera.com (8.10.1/UW7.1.1-NSCd) with ESMTP id g24F6gI26406; Mon, 4 Mar 2002 10:06:42 -0500 (EST) Message-ID: <3C838D82.A9CEA74B@caldera.com> Date: Mon, 04 Mar 2002 10:06:42 -0500 From: Sergey Babkin Organization: Caldera International, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: Tony Finch Cc: chawla@caldera.com, arch@freebsd.org Subject: Re: proposition for new socket syscalls {send,recv}fromto References: <20020303195801.A17586@chiark.greenend.org.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Tony Finch wrote: > > I agree that these calls are necessary and should have been presend from > the start, but you seem to be unaware of the usual way of implementing > UDP servers that are aware of multihoming, such as BIND. They typically > use SIOCGIFADDR to read the list of interfaces on the machine then bind > a socket to each one. The server can choose the appropriate socket to > use according to the source address that is required. However this > doesn't deal all that well with a dynamically changing list of interface > addresses... Hm, from looking at the BIND code it seems to reload the list of interfaces periodically, so it can handle the changing list of interfaces. And it has a fair amount of code dealing with it. But not all the servers do this: for instance, tftpd does not. -SB -- Sergey Babkin sergey@caldera.com Escalations Research Group, Caldera - NJ (908)790-2385 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 7:12:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nimbus.nj.caldera.com (nimbus.nj.caldera.com [132.147.103.56]) by hub.freebsd.org (Postfix) with ESMTP id 33EC937B434 for ; Mon, 4 Mar 2002 07:11:54 -0800 (PST) Received: from caldera.com (bird [132.147.135.198]) by nimbus.nj.caldera.com (8.10.1/UW7.1.1-NSCd) with ESMTP id g24FBlI26694; Mon, 4 Mar 2002 10:11:48 -0500 (EST) Message-ID: <3C838EB3.C38E23D2@caldera.com> Date: Mon, 04 Mar 2002 10:11:47 -0500 From: Sergey Babkin Organization: Caldera International, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: Ian Dowse Cc: arch@freebsd.org, chawla@caldera.com, Christoph Hellwig , davem@redhat.com Subject: Re: proposition for new socket syscalls {send,recv}fromto References: <200203020245.aa34899@salmon.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ian Dowse wrote: > > In message <3C800A80.96CEA9D2@caldera.com>, Sergey Babkin writes: > > > >The fix in short: the server should do a bind() to the right address > >before doing the reply. However in practice this code gets much more > >compilcated and ugly, as will be discussed further. > > Linux has an IP_PKTINFO socket option and IP_PKTINFO control message > that (I think) allows you record the destination IP on incoming > datagrams and set the source address on outgoing ones. A quick, > minimally tested sample program which uses it is at: > > http://www.maths.tcd.ie/~iedowse/FreeBSD/pktinfo.c It's doing essentially the same thing as I described with IP_RECVDSTADDR, I guess IP_RECVDSTADDR returns a subset of information returned by IP_PKTINFO. > In FreeBSD, we only seem to have this capability for IPv6, using > the IPV6_PKTINFO option and control messages. Implementations of > either an IP_PKTINFO or an IP_SENDSRCADDR control message have been > discussed on freebsd-net a few times, but nothing has been committed > yet. Yes, IP_SENDSRCADDR would make the sending side of things a lot easier. > For systems that have such a mechanism, the proposed syscalls could > just be implemented as library functions instead. Agreed. -SB -- Sergey Babkin sergey@caldera.com Escalations Research Group, Caldera - NJ (908)790-2385 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 9: 6:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 869B637B416 for ; Mon, 4 Mar 2002 09:06:12 -0800 (PST) Received: from pool0036.cvx22-bradley.dialup.earthlink.net ([209.179.198.36] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16hvuc-0001Ce-00 for arch@freebsd.org; Mon, 04 Mar 2002 09:06:11 -0800 Message-ID: <3C83A974.96E2895C@mindspring.com> Date: Mon, 04 Mar 2002 09:05:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: proposition for new socket syscalls {send,recv}fromto Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > I agree that these calls are necessary and should have been presend from > > the start, but you seem to be unaware of the usual way of implementing > > UDP servers that are aware of multihoming, such as BIND. They typically > > use SIOCGIFADDR to read the list of interfaces on the machine then bind > > a socket to each one. The server can choose the appropriate socket to > > use according to the source address that is required. However this > > doesn't deal all that well with a dynamically changing list of interface > > addresses... > > Hm, from looking at the BIND code it seems to reload the list of interfaces > periodically, so it can handle the changing list of interfaces. And it has > a fair amount of code dealing with it. But not all the servers do this: > for instance, tftpd does not. On the receive side, the problem isn't interfaces so much as it is IP addresses. Specifically, the problem is that it's binding to the IP addresses in the first place, rather than binding to the interfaces, regardless of which IP addresses are or are not on them. From the original posting about the failover scenario with IP takeover, the takeover issue would be resolved, in the receive case by simply binding to the interface rather than addresses. IP addresses could then come and go, and the daemon would get the packets when the IP was there, and not when the IP wasn't. I've often wanted this capability on dialup gateway machines, where the daemons would not require restart, if the bind were this way, and the local host name was not cached data from an interface probe (e.g. sendmail's idea of the name to give in the EHLO on outbound or the name to give in the greeting on inbound). On the send case, the main issue is, I think, responses. In fact, I can't easily come up with a non-hacking case where there is not a packet on a know interface that is eliciting a reply on an unknown interface that is not handled by response only. This implies that a receive of the packet with source information -- something which is already handled in the context of the existing API -- is enough, if there is a "sendfrom" which took the receive context for the reply; I would want the sendfrom, however, to verify that the address it was sending from was in fact local. Another issue that occurst to me, but is only slightly related to the API issue, if at all, is that it should be possible to add an option to the "ifconfig" of an address or alias, such that the local machine did not ARP for the IP address. Specifically, for DSR (Direct SErver Return), this is a requirement to avoid confusing Cisco, Extreme Networks, and other switches. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 10:10:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id BA45437B405 for ; Mon, 4 Mar 2002 10:10:54 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020304181054.NQYM1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Mon, 4 Mar 2002 18:10:54 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g24IAna87997; Mon, 4 Mar 2002 10:10:49 -0800 (PST) (envelope-from cjc) Date: Mon, 4 Mar 2002 10:10:49 -0800 From: "Crist J. Clark" To: Archie Cobbs Cc: Julian Elischer , freebsd-arch@FreeBSD.ORG Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020304101049.D87533@blossom.cjclark.org> References: <200203040455.g244tr429559@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200203040455.g244tr429559@arch20m.dellroad.org>; from archie@dellroad.org on Sun, Mar 03, 2002 at 08:55:53PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Mar 03, 2002 at 08:55:53PM -0800, Archie Cobbs wrote: > Julian Elischer writes: > > I think loopback is not really 'optional' and should come as soon > > as you have any networking at all. > > Why? From a theoretical standpoint, there's nothing mandatory > about it. E.g., consider a machine that is only a router, has > no users, etc. It doesn't need one. Try to build a kernel without, pseudo-device loop # Network loopback And see what happens. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 10:23:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 55C4737B405; Mon, 4 Mar 2002 10:23:36 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g24INZJ31017; Mon, 4 Mar 2002 10:23:35 -0800 Date: Mon, 4 Mar 2002 10:23:35 -0800 From: Brooks Davis To: "Crist J. Clark" Cc: Archie Cobbs , Julian Elischer , freebsd-arch@FreeBSD.ORG Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020304102335.A27553@Odin.AC.HMC.Edu> References: <200203040455.g244tr429559@arch20m.dellroad.org> <20020304101049.D87533@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020304101049.D87533@blossom.cjclark.org>; from cjc@FreeBSD.ORG on Mon, Mar 04, 2002 at 10:10:49AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 04, 2002 at 10:10:49AM -0800, Crist J. Clark wrote: > On Sun, Mar 03, 2002 at 08:55:53PM -0800, Archie Cobbs wrote: > > Why? From a theoretical standpoint, there's nothing mandatory > > about it. E.g., consider a machine that is only a router, has > > no users, etc. It doesn't need one. >=20 > Try to build a kernel without, >=20 > pseudo-device loop # Network loopback >=20 > And see what happens. =46rom a _practical_ standpoint, a loopback interface must be compiled in at this time. However, that's not what Archie and I are arguing. I'm arguing that since the requirement is not there in theory, we should not be making moves which require it in practice. The direction I'd like to move in would be toward making loopback loadable and adding appropriate module depends so it gets loaded or compiled in automaticly (with peter's new kernel config/build system) when IP networking is enabled. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8g7unXY6L6fI4GtQRArktAJsHKlz+6Y2aAXovAmfvedZoKKsqdgCfaTFO Vo0lvFIjptwZx5FEok12h44= =Hrvb -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 10:24:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 0DF8D37B41E for ; Mon, 4 Mar 2002 10:23:48 -0800 (PST) Received: (qmail 27438 invoked by uid 1000); 4 Mar 2002 18:24:04 -0000 Date: Mon, 4 Mar 2002 20:24:04 +0200 From: Peter Pentchev To: "Crist J. Clark" Cc: Archie Cobbs , Julian Elischer , freebsd-arch@FreeBSD.ORG Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020304202404.B1633@straylight.oblivion.bg> Mail-Followup-To: "Crist J. Clark" , Archie Cobbs , Julian Elischer , freebsd-arch@FreeBSD.ORG References: <200203040455.g244tr429559@arch20m.dellroad.org> <20020304101049.D87533@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020304101049.D87533@blossom.cjclark.org>; from cjc@FreeBSD.ORG on Mon, Mar 04, 2002 at 10:10:49AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 04, 2002 at 10:10:49AM -0800, Crist J. Clark wrote: > On Sun, Mar 03, 2002 at 08:55:53PM -0800, Archie Cobbs wrote: > > Julian Elischer writes: > > > I think loopback is not really 'optional' and should come as soon=20 > > > as you have any networking at all. > >=20 > > Why? From a theoretical standpoint, there's nothing mandatory > > about it. E.g., consider a machine that is only a router, has > > no users, etc. It doesn't need one. >=20 > Try to build a kernel without, >=20 > pseudo-device loop # Network loopback >=20 > And see what happens. I think that you and Archie are speaking at cross purposes; he means that the loopback interface is not really necessary for any theoretical networking model, while you point out that the assumption that there will always be a loopback interface has gained very firm ground in many places all around the network subsystem of the FreeBSD kernel. In theory, it should still be possible to rework the code in those places, so that the kernel does not rely on the loopback all that much :) (Not that I would be the one to actually try to *do* that.. :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyDu8QACgkQ7Ri2jRYZRVP0WACgh4ZuRhlXHbj5G18amN8TiAQj 1fwAnAsdXkK/O5n4zwM9TeRQB0ReS0kS =tXz9 -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 10:25:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.22.195.2]) by hub.freebsd.org (Postfix) with ESMTP id D35A537B41B for ; Mon, 4 Mar 2002 10:25:50 -0800 (PST) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 16hx9c-0003Mo-00 (Debian); Mon, 04 Mar 2002 18:25:44 +0000 Date: Mon, 4 Mar 2002 18:25:44 +0000 From: Tony Finch To: Sergey Babkin Cc: Tony Finch , chawla@caldera.com, arch@freebsd.org Subject: Re: proposition for new socket syscalls {send,recv}fromto Message-ID: <20020304182544.A2716@chiark.greenend.org.uk> References: <20020303195801.A17586@chiark.greenend.org.uk> <3C838D82.A9CEA74B@caldera.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C838D82.A9CEA74B@caldera.com>; from sergey@caldera.com on Mon, Mar 04, 2002 at 10:06:42AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 04, 2002 at 10:06:42AM -0500, Sergey Babkin wrote: > > And it has a fair amount of code dealing with it. Yes, and ugly code at that. I'm not surprised that tftpd doesn't bother. Tony. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 10:32:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 037F337B402; Mon, 4 Mar 2002 10:32:43 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g24IWgt67718; Mon, 4 Mar 2002 10:32:42 -0800 (PST) (envelope-from rizzo) Date: Mon, 4 Mar 2002 10:32:42 -0800 From: Luigi Rizzo To: Brooks Davis Cc: "Crist J. Clark" , Archie Cobbs , Julian Elischer , freebsd-arch@FreeBSD.ORG Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020304103242.A67658@iguana.icir.org> References: <200203040455.g244tr429559@arch20m.dellroad.org> <20020304101049.D87533@blossom.cjclark.org> <20020304102335.A27553@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020304102335.A27553@Odin.AC.HMC.Edu> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 04, 2002 at 10:23:35AM -0800, Brooks Davis wrote: > From a _practical_ standpoint, a loopback interface must be compiled > in at this time. However, that's not what Archie and I are arguing. > I'm arguing that since the requirement is not there in theory, we should > not be making moves which require it in practice. The direction I'd like speaking of which , would it be reasonable to merge if_disc and if_loop ? The former is basically a stripped down version of the latter, so it hardly justifies a separate device cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 10:41:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 4CD4C37B405; Mon, 4 Mar 2002 10:41:31 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g24IfU706041; Mon, 4 Mar 2002 10:41:30 -0800 Date: Mon, 4 Mar 2002 10:41:30 -0800 From: Brooks Davis To: Luigi Rizzo Cc: "Crist J. Clark" , Archie Cobbs , Julian Elischer , freebsd-arch@FreeBSD.ORG Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020304104130.A3499@Odin.AC.HMC.Edu> References: <200203040455.g244tr429559@arch20m.dellroad.org> <20020304101049.D87533@blossom.cjclark.org> <20020304102335.A27553@Odin.AC.HMC.Edu> <20020304103242.A67658@iguana.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020304103242.A67658@iguana.icir.org>; from rizzo@icir.org on Mon, Mar 04, 2002 at 10:32:42AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 04, 2002 at 10:32:42AM -0800, Luigi Rizzo wrote: > speaking of which , would it be reasonable to merge if_disc and if_loop ? > The former is basically a stripped down version of the latter, so > it hardly justifies a separate device Given that if_disc is not generally used and all of 213 lines (including comments), I'd probably be inclinded to leave it seperate. From a purly theoretical perspective you might want a disc device, but not loop device in some strange networking system. The other things that makes me think we should keep things the same is that if we combined them, we'd have a single, odd, multi-function driver instead of two very simple drivers which would be a lose in terms of allowing new programmers to see a truly minimal network interface. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8g7/aXY6L6fI4GtQRAuB0AJ4k7ckXnNvk3Bdp66hCNEDrgHhK2gCePH0y c/ktQ9Xt4P0OeV7GJuWn/NE= =gXlz -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 10:45: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id B58C437B400 for ; Mon, 4 Mar 2002 10:45:04 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020304184504.MLZW2626.rwcrmhc51.attbi.com@blossom.cjclark.org>; Mon, 4 Mar 2002 18:45:04 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g24Ij4588118; Mon, 4 Mar 2002 10:45:04 -0800 (PST) (envelope-from cjc) Date: Mon, 4 Mar 2002 10:45:04 -0800 From: "Crist J. Clark" To: Archie Cobbs , Julian Elischer , freebsd-arch@FreeBSD.ORG Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020304104504.F87533@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <200203040455.g244tr429559@arch20m.dellroad.org> <20020304101049.D87533@blossom.cjclark.org> <20020304202404.B1633@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020304202404.B1633@straylight.oblivion.bg>; from roam@ringlet.net on Mon, Mar 04, 2002 at 08:24:04PM +0200 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 04, 2002 at 08:24:04PM +0200, Peter Pentchev wrote: > On Mon, Mar 04, 2002 at 10:10:49AM -0800, Crist J. Clark wrote: > > On Sun, Mar 03, 2002 at 08:55:53PM -0800, Archie Cobbs wrote: > > > Julian Elischer writes: > > > > I think loopback is not really 'optional' and should come as soon > > > > as you have any networking at all. > > > > > > Why? From a theoretical standpoint, there's nothing mandatory > > > about it. E.g., consider a machine that is only a router, has > > > no users, etc. It doesn't need one. > > > > Try to build a kernel without, > > > > pseudo-device loop # Network loopback > > > > And see what happens. > > I think that you and Archie are speaking at cross purposes; > he means that the loopback interface is not really necessary > for any theoretical networking model, while you point out that > the assumption that there will always be a loopback interface > has gained very firm ground in many places all around the network > subsystem of the FreeBSD kernel. In theory, it should still be > possible to rework the code in those places, so that the kernel > does not rely on the loopback all that much :) > > (Not that I would be the one to actually try to *do* that.. :) Exactly. I was just pointing out that this may not exactly be a trivial thing to do in practice. It may not need a loopback in a theoretical sense, but you need one to build the network code as it is currently written. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 11:21: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id C11A937B41A; Mon, 4 Mar 2002 11:20:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020304192015.QCOC1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 4 Mar 2002 19:20:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA26898; Mon, 4 Mar 2002 11:14:04 -0800 (PST) Date: Mon, 4 Mar 2002 11:14:04 -0800 (PST) From: Julian Elischer To: Luigi Rizzo Cc: Brooks Davis , "Crist J. Clark" , Archie Cobbs , freebsd-arch@FreeBSD.ORG Subject: Re: Patches to if_loop + the interface cloning framework In-Reply-To: <20020304103242.A67658@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Luigi Rizzo wrote: > speaking of which , would it be reasonable to merge if_disc and if_loop ? > The former is basically a stripped down version of the latter, so > it hardly justifies a separate device > I think I'd rather keep them separate. Why complicate either of them? (anyhow it would be difficult to have a separate if_disc .ko module if it were compiled into the loopback. It's not a great complicated thing.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 11:24:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id DA6EB37B402; Mon, 4 Mar 2002 11:24:28 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g24JO6Lv080825; Mon, 4 Mar 2002 20:24:07 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Luigi Rizzo Cc: Brooks Davis , "Crist J. Clark" , Archie Cobbs , Julian Elischer , freebsd-arch@FreeBSD.ORG Subject: Re: Patches to if_loop + the interface cloning framework In-Reply-To: Your message of "Mon, 04 Mar 2002 10:32:42 PST." <20020304103242.A67658@iguana.icir.org> Date: Mon, 04 Mar 2002 20:24:06 +0100 Message-ID: <80824.1015269846@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020304103242.A67658@iguana.icir.org>, Luigi Rizzo writes: >On Mon, Mar 04, 2002 at 10:23:35AM -0800, Brooks Davis wrote: >> From a _practical_ standpoint, a loopback interface must be compiled >> in at this time. However, that's not what Archie and I are arguing. >> I'm arguing that since the requirement is not there in theory, we should >> not be making moves which require it in practice. The direction I'd like > >speaking of which , would it be reasonable to merge if_disc and if_loop ? >The former is basically a stripped down version of the latter, so >it hardly justifies a separate device I find if_disc useful sometimes, in particular being able to blackhole trafic and use SNMP to monitor the throughput. If you can merge it into if_loop in a sensible way I'm all for it. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 14:32:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id F101C37B402 for ; Mon, 4 Mar 2002 14:32:37 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g24MWPLv017281 for ; Mon, 4 Mar 2002 23:32:25 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: kernel process priority question... From: Poul-Henning Kamp Date: Mon, 04 Mar 2002 23:32:25 +0100 Message-ID: <17280.1015281145@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG What is the correct way to set a priority on a kernel thread ? Is it legal to simply set the value like this: curthread->td_base_pri = PRIBIO; Or should the detour around the rtprio stuff be used: struct rtprio rtp; rtp.prio = RTP_PRIO_MAX; rtp.type = RTP_PRIO_IDLE; mtx_lock_spin(&sched_lock); rtp_to_pri(&rtp, td->td_ksegrp); mtx_unlock_spin(&sched_lock); -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 4 21:55:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from networld.com (relay.networld.com [65.88.251.103]) by hub.freebsd.org (Postfix) with ESMTP id E98D837B400 for ; Mon, 4 Mar 2002 21:55:31 -0800 (PST) Received: from [65.88.244.127] (HELO softweyr.com) by networld.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 14326779; Mon, 04 Mar 2002 22:49:54 -0700 Message-ID: <3C845EAC.9000106@softweyr.com> Date: Mon, 04 Mar 2002 22:59:08 -0700 From: Wes Peters User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Stephane E. Potvin" Cc: Joe Magura , freebsd-arch@FreeBSD.ORG Subject: Re: Strong Arm? References: <3C7E598A.7040402@softweyr.com> <20020304120724.A98515@hades.videotron.ca.> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Stephane E. Potvin wrote: > On Thu, Feb 28, 2002 at 09:23:38AM -0700, Wes Peters wrote: > >>Joe Magura wrote: >> >>>Folks, >>> >>> Any work being done on Strong Arm platform or any other "PocketPC" >>>platforms? >> >>Yes, but it's being done over in the NetBSD project. (: > > I sure don't want to disagree with you but there is currently work being done > porting FreeBSD to the arm processor. It's not far down the road (I'm not that > good a kernel hacker to finish in a few weeks) but it's progressing :) That's good to know. What machine are you using for development work? I'm interested in following your progress. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 3:27: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7AE9037B405 for ; Tue, 5 Mar 2002 03:26:54 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA20268; Tue, 5 Mar 2002 22:26:32 +1100 Date: Tue, 5 Mar 2002 22:27:23 +1100 (EST) From: Bruce Evans X-X-Sender: To: Seigo Tanimura Cc: Matthew Dillon , Terry Lambert , Subject: Re: reclaiming v_data of free vnodes In-Reply-To: <200203031242.g23CfIfu059069@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Message-ID: <20020305214534.S4601-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 3 Mar 2002, Seigo Tanimura wrote: > Attached is the patch to use the zone allocator for in-core inodes. What are the advantages of the zone allocator here? Ordinary malloc() works, or should work, perfectly for ffs inodes because the size of an ffs inode is a power of 2 (256), and inodes are rarely allocated or deallocated so efficiency is unimportant. I believe the only problem with malloc() is that it never frees small allocations. This is not hard to fix. I fixed it in FreeBSD-1. This involved little more than fixing the "Couldfree" stuff so that it is actually useful. (Note that "Couldfree" column in vmstat output doesn't show the number of allocations that could be freed. This is usually obvious, since it is usually larger than the "Free" column for popular sizes after the system has been running for a while. IIRC, it shows the number of missed opportunities to free a page.) > On Tue, 26 Feb 2002 18:23:45 +0900, > Seigo Tanimura said: > > Seigo> AFAIK, all of ffs, ifs and ext2fs utilize struct inode and > Seigo> dinode. They deal with the filesystem-specific data by a union. All of > Seigo> the filesystems should thus be able to share a single zone. The sharing is just a bug in the case of ext2fs, and other file systems (msdosfs, cd9660, ...) are too different to share. Your patch is very large due to namespace pollution. vm_zone_t should be opaque in the same way as "struct malloc_type" so that it can be used in headers without everything having to include and . Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 4:26: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id EC5B337B417; Tue, 5 Mar 2002 04:23:20 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA24088; Tue, 5 Mar 2002 23:23:19 +1100 Date: Tue, 5 Mar 2002 23:24:10 +1100 (EST) From: Bruce Evans X-X-Sender: To: Poul-Henning Kamp Cc: Subject: Re: kernel process priority question... In-Reply-To: <17280.1015281145@critter.freebsd.dk> Message-ID: <20020305223033.M4715-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Poul-Henning Kamp wrote: > What is the correct way to set a priority on a kernel thread ? > > Is it legal to simply set the value like this: > > curthread->td_base_pri = PRIBIO; > > Or should the detour around the rtprio stuff be used: > > struct rtprio rtp; > > rtp.prio = RTP_PRIO_MAX; > rtp.type = RTP_PRIO_IDLE; > mtx_lock_spin(&sched_lock); > rtp_to_pri(&rtp, td->td_ksegrp); > mtx_unlock_spin(&sched_lock); Neither. The rtprio stuff should be just compatibility cruft to support the rtprio(2) mistake (extending {get,set}priority(2) would have been a smaller mistake, but even these were obsoleted by the POSIX.1-1993 about a year before rtprio(2) was committed). When setting priority fields directly, there are 4 of them in places that keep being moved by KSE changes, and the setting may need locking, so a function to hide the details would be useful. rtp_to_prio() is not that function. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 7:54:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 0B5FF37B43A for ; Tue, 5 Mar 2002 07:52:33 -0800 (PST) Received: (qmail 14540 invoked from network); 5 Mar 2002 15:52:25 -0000 Received: from unknown (HELO server.baldwin.cx) ([65.91.137.49]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Mar 2002 15:52:26 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g25Fq5G57146; Tue, 5 Mar 2002 10:52:05 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020305223033.M4715-100000@gamplex.bde.org> Date: Tue, 05 Mar 2002 10:51:52 -0500 (EST) From: John Baldwin To: Bruce Evans Subject: Re: kernel process priority question... Cc: arch@FreeBSD.ORG, Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 05-Mar-02 Bruce Evans wrote: > On Mon, 4 Mar 2002, Poul-Henning Kamp wrote: > >> What is the correct way to set a priority on a kernel thread ? >> >> Is it legal to simply set the value like this: >> >> curthread->td_base_pri = PRIBIO; >> >> Or should the detour around the rtprio stuff be used: >> >> struct rtprio rtp; >> >> rtp.prio = RTP_PRIO_MAX; >> rtp.type = RTP_PRIO_IDLE; >> mtx_lock_spin(&sched_lock); >> rtp_to_pri(&rtp, td->td_ksegrp); >> mtx_unlock_spin(&sched_lock); > > Neither. > > The rtprio stuff should be just compatibility cruft to support the > rtprio(2) mistake (extending {get,set}priority(2) would have been a > smaller mistake, but even these were obsoleted by the POSIX.1-1993 > about a year before rtprio(2) was committed). > > When setting priority fields directly, there are 4 of them in places > that keep being moved by KSE changes, and the setting may need locking, > so a function to hide the details would be useful. rtp_to_prio() is > not that function. Yes, the priority stuff is still rather a mess in the wake of KSE right now. For example, resetpriority() and updatepri() try to mix updating per-KSE group prioritites (user priorities) with the priority of the current thread. Cleaning all this up is teh biggest thing the preemption code is waiting on (aside from all the preemption bugs :) > Bruce -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 10: 0:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id DF00937B41A; Tue, 5 Mar 2002 10:00:25 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305180025.TMXZ1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 18:00:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA31641; Tue, 5 Mar 2002 09:47:19 -0800 (PST) Date: Tue, 5 Mar 2002 09:47:18 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: kernel process priority question... In-Reply-To: <20020305223033.M4715-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The person to ask is jhb, but I think that the first option is closest. td_base_pri is the base kernel priority that the process has WITHOUT PRIORITY INHERRITANCE. This is what is increased (or should be) when you specify a priority in msleep, and it wakes up. The instant priority is td->td_priority. This is what the priority is right now, including priority inheritance from mutexes wanted by others. When you go back to userland yuor priority will be reset back to kg->kg_user_pri, which is common for all thread in the scheduling group. If you are changing td_base_pri, you may need to change td_priority as well if you want it to have any effect. (I need to look at msleep to see if this is done right) td->td_priority = min(td->td_base_pri, td->td_priority); i.e. if the new base pri is more (lower than) the current priority, then boost the current priority too. On Tue, 5 Mar 2002, Bruce Evans wrote: > On Mon, 4 Mar 2002, Poul-Henning Kamp wrote: > > > What is the correct way to set a priority on a kernel thread ? > > > > Is it legal to simply set the value like this: > > > > curthread->td_base_pri = PRIBIO; > > > > Or should the detour around the rtprio stuff be used: > > > > struct rtprio rtp; > > > > rtp.prio = RTP_PRIO_MAX; > > rtp.type = RTP_PRIO_IDLE; > > mtx_lock_spin(&sched_lock); > > rtp_to_pri(&rtp, td->td_ksegrp); > > mtx_unlock_spin(&sched_lock); > > Neither. > > The rtprio stuff should be just compatibility cruft to support the > rtprio(2) mistake (extending {get,set}priority(2) would have been a > smaller mistake, but even these were obsoleted by the POSIX.1-1993 > about a year before rtprio(2) was committed). > > When setting priority fields directly, there are 4 of them in places > that keep being moved by KSE changes, and the setting may need locking, > so a function to hide the details would be useful. rtp_to_prio() is > not that function. > > Bruce > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 10:17:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6961737B426 for ; Tue, 5 Mar 2002 10:17:22 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g25IHLm71569; Tue, 5 Mar 2002 10:17:21 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Mar 2002 10:17:21 -0800 (PST) From: Matthew Dillon Message-Id: <200203051817.g25IHLm71569@apollo.backplane.com> To: Seigo Tanimura , Bruce Evans , Terry Lambert , Subject: Re: reclaiming v_data of free vnodes References: <20020305214534.S4601-100000@gamplex.bde.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I also have some worries. The main worry is that the zone allocator never returns memory to the system. Kernel malloc at least is able to reuse freed memory between subsystems. This has become glaringly obvious to me in recent weeks by virtue of the fork and process resource issues that I've been helping Mike Silbersack out on. Anything 'large' that commits VM to zalloc in -stable becomes a permanent fixture in the system. The kernel malloc subsystem is at least able to handle memory load shifts between subsystems. It isn't great at it, but it will do it. The zalloc subsystem cannot shift loads at all and as a consequence we already have problems with the system running out of KVM. I think our best bet is to either (1) adjust the existing kernel malloc to handle odd-sized structures more efficiently. e.g. like introduce a '192' chunk size inbetween '128' and '256'. Or, (2) just continue patching problems with silly putty until -stable becomes obsolete. Jeff's slab allocator work in -current promises to solve the zalloc/malloc issue for us in -current. Note that I am not trying to veto this work, I am just registering my opinion that it will not help the overall situation. -Matt Matthew Dillon :On Sun, 3 Mar 2002, Seigo Tanimura wrote: : :> Attached is the patch to use the zone allocator for in-core inodes. : :What are the advantages of the zone allocator here? Ordinary malloc() :works, or should work, perfectly for ffs inodes because the size of :an ffs inode is a power of 2 (256), and inodes are rarely allocated :or deallocated so efficiency is unimportant. I believe the only problem :with malloc() is that it never frees small allocations. This is not :hard to fix. I fixed it in FreeBSD-1. This involved little more than :fixing the "Couldfree" stuff so that it is actually useful. (Note :that "Couldfree" column in vmstat output doesn't show the number of :allocations that could be freed. This is usually obvious, since it :is usually larger than the "Free" column for popular sizes after the :system has been running for a while. IIRC, it shows the number of :missed opportunities to free a page.) : :> On Tue, 26 Feb 2002 18:23:45 +0900, :> Seigo Tanimura said: :> :> Seigo> AFAIK, all of ffs, ifs and ext2fs utilize struct inode and :> Seigo> dinode. They deal with the filesystem-specific data by a union. All of :> Seigo> the filesystems should thus be able to share a single zone. : :The sharing is just a bug in the case of ext2fs, and other file systems :(msdosfs, cd9660, ...) are too different to share. : :Your patch is very large due to namespace pollution. vm_zone_t should :be opaque in the same way as "struct malloc_type" so that it can be :used in headers without everything having to include and :. : :Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 13:49:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id F269D37B400 for ; Tue, 5 Mar 2002 13:49:32 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g25LnWg79752; Tue, 5 Mar 2002 13:49:32 -0800 (PST) (envelope-from rizzo) Date: Tue, 5 Mar 2002 13:49:32 -0800 From: Luigi Rizzo To: arch@freebsd.org Subject: do we need full kernel sources to compile loadable modules ? Message-ID: <20020305134932.A79697@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Plain and simple... I thought one could compile a kernel extension (foo.ko) without full kernel sources, as the various include files describing kernel interfaces and data structures are installed in various places under /usr/include . This seems to work fine in many cases. Turns out, however, that at least one thing (namely vnode_if.h) is not there, and it needs to be reconstructed using sys/kern/vnode_if.{pl,src} So i wonder: + is it a desirable goal that one can compile kernel extensions without requiring a full kernel source tree ? + if so, shouldn't we make sure that, as part of the creation of /usr/include, a copy of vnode_if.h is generated somewhere (maybe in /usr/include/sys or wherever is more appropriate) ? + are there other header files (and maybe objects, e.g. there is also a vnode_if.o) which have similar problems ? cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 14: 8:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from phoenix.dmnshq.net (phoenix.dmnshq.net [194.19.34.94]) by hub.freebsd.org (Postfix) with SMTP id CC9E237B405 for ; Tue, 5 Mar 2002 14:08:23 -0800 (PST) Received: (from eivind@localhost) by phoenix.dmnshq.net (8.11.6/8.11.6) id g25M7c771796; Tue, 5 Mar 2002 23:07:38 +0100 (CET) (envelope-from eivind) Date: Tue, 5 Mar 2002 23:07:38 +0100 From: Eivind Eklund To: Luigi Rizzo Cc: arch@FreeBSD.ORG Subject: Re: do we need full kernel sources to compile loadable modules ? Message-ID: <20020305230738.C13979@phoenix.dmnshq.net> References: <20020305134932.A79697@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020305134932.A79697@iguana.icir.org>; from rizzo@icir.org on Tue, Mar 05, 2002 at 01:49:32PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 01:49:32PM -0800, Luigi Rizzo wrote: > Plain and simple... I thought one could compile a kernel extension > (foo.ko) without full kernel sources, as the various include files > describing kernel interfaces and data structures are installed in > various places under /usr/include . > This seems to work fine in many cases. > > Turns out, however, that at least one thing (namely vnode_if.h) is not > there, and it needs to be reconstructed using sys/kern/vnode_if.{pl,src} > > So i wonder: > > + is it a desirable goal that one can compile kernel extensions without > requiring a full kernel source tree ? > > + if so, shouldn't we make sure that, as part of the creation of > /usr/include, a copy of vnode_if.h is generated somewhere (maybe > in /usr/include/sys or wherever is more appropriate) ? > > + are there other header files (and maybe objects, e.g. there is also > a vnode_if.o) which have similar problems ? There is probably similar problems with newbus. We have previously talked about making vnode_if.src be handled similar to syscalls.master - ie, generate files from it, then commit those files. I don't think there would be many protests if this was implemented (in a clean fashion). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 14:45:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by hub.freebsd.org (Postfix) with ESMTP id 82B9B37B405 for ; Tue, 5 Mar 2002 14:45:23 -0800 (PST) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g25MjIs37463; Tue, 5 Mar 2002 14:45:18 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.1/8.12.1/meer) with ESMTP id g25MjHcI053673; Tue, 5 Mar 2002 14:45:22 -0800 (PST) Message-Id: <200203052245.g25MjHcI053673@mail.meer.net> To: Luigi Rizzo Cc: arch@FreeBSD.ORG Subject: Re: do we need full kernel sources to compile loadable modules ? In-Reply-To: Message from Luigi Rizzo of "Tue, 05 Mar 2002 13:49:32 PST." <20020305134932.A79697@iguana.icir.org> Date: Tue, 05 Mar 2002 14:45:17 -0800 From: "George V. Neville-Neil" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > + is it a desirable goal that one can compile kernel extensions without > requiring a full kernel source tree ? That sounds like a good goal. If it's just one file then isn't that just a mistake to be fixed? Later, George To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 14:55:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id A48FB37B405; Tue, 5 Mar 2002 14:55:47 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g25Mtmn37671; Tue, 5 Mar 2002 14:55:48 -0800 (PST) (envelope-from obrien) Date: Tue, 5 Mar 2002 14:54:06 -0800 From: "David O'Brien" To: Eivind Eklund Cc: Luigi Rizzo , arch@FreeBSD.ORG Subject: Re: do we need full kernel sources to compile loadable modules ? Message-ID: <20020305145406.A37648@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020305134932.A79697@iguana.icir.org> <20020305230738.C13979@phoenix.dmnshq.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020305230738.C13979@phoenix.dmnshq.net>; from eivind@FreeBSD.ORG on Tue, Mar 05, 2002 at 11:07:38PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 11:07:38PM +0100, Eivind Eklund wrote: > There is probably similar problems with newbus. We have previously talked > about making vnode_if.src be handled similar to syscalls.master - ie, generate > files from it, then commit those files. I think this would be a mistake. We should strive to not commit the generated form of syscalls.master. We've seen just too often people forget to do this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 5 16:51:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 36BCA37B402; Tue, 5 Mar 2002 16:51:51 -0800 (PST) Received: from pool0228.cvx40-bradley.dialup.earthlink.net ([216.244.42.228] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iPem-0005NT-00; Tue, 05 Mar 2002 16:51:48 -0800 Message-ID: <3C85680B.776B76CD@mindspring.com> Date: Tue, 05 Mar 2002 16:51:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: obrien@FreeBSD.ORG Cc: Eivind Eklund , Luigi Rizzo , arch@FreeBSD.ORG Subject: Re: do we need full kernel sources to compile loadable modules ? References: <20020305134932.A79697@iguana.icir.org> <20020305230738.C13979@phoenix.dmnshq.net> <20020305145406.A37648@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Tue, Mar 05, 2002 at 11:07:38PM +0100, Eivind Eklund wrote: > > There is probably similar problems with newbus. We have previously > > talked about making vnode_if.src be handled similar to syscalls.master > > - ie, generate files from it, then commit those files. > > I think this would be a mistake. We should strive to not commit the > generated form of syscalls.master. We've seen just too often people > forget to do this. Yes, it's pretty evil. AIX had a different way, in which the linker could read a system call table that had name/entry point # pairs, and you could add to this table on the fly, if you wanted the linker to know about new system calls; it would just generate the stub functions automatically. This is evil, too, but the fact that you have to rebuild libc to add a system call stub is pretty much as painful as it gets. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 0:37: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id E12C537B416; Wed, 6 Mar 2002 00:37:02 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g268b0L83830; Wed, 6 Mar 2002 00:37:00 -0800 (PST) (envelope-from rizzo) Date: Wed, 6 Mar 2002 00:37:00 -0800 From: Luigi Rizzo To: Terry Lambert Cc: obrien@FreeBSD.ORG, Eivind Eklund , arch@FreeBSD.ORG Subject: Re: do we need full kernel sources to compile loadable modules ? Message-ID: <20020306003700.A83775@iguana.icir.org> References: <20020305134932.A79697@iguana.icir.org> <20020305230738.C13979@phoenix.dmnshq.net> <20020305145406.A37648@dragon.nuxi.com> <3C85680B.776B76CD@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C85680B.776B76CD@mindspring.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I agree on the comments on the generated files, I was just asking if we could, as part of the install of include files, include some rule in the makefile so that it would generate a copy of vnode_if.h somewhere in the include tree. cheers luigi On Tue, Mar 05, 2002 at 04:51:23PM -0800, Terry Lambert wrote: > David O'Brien wrote: > > > > On Tue, Mar 05, 2002 at 11:07:38PM +0100, Eivind Eklund wrote: > > > There is probably similar problems with newbus. We have previously > > > talked about making vnode_if.src be handled similar to syscalls.master > > > - ie, generate files from it, then commit those files. > > > > I think this would be a mistake. We should strive to not commit the > > generated form of syscalls.master. We've seen just too often people > > forget to do this. > > Yes, it's pretty evil. > > AIX had a different way, in which the linker could read a > system call table that had name/entry point # pairs, and > you could add to this table on the fly, if you wanted the > linker to know about new system calls; it would just > generate the stub functions automatically. > > This is evil, too, but the fact that you have to rebuild > libc to add a system call stub is pretty much as painful > as it gets. > > -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 7:57:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id A850037B402 for ; Wed, 6 Mar 2002 07:57:11 -0800 (PST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp [IPv6:3ffe:b80:5b0:3:280:c8ff:fe6b:6d73]) by rina.r.dl.itc.u-tokyo.ac.jp (8.12.2/3.7W-rina.r-Nankai-Koya) with ESMTP id g26Fv7lo016599 ; Thu, 7 Mar 2002 00:57:08 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.12.2/3.7W-carrots-Keikyu-Kurihama) with ESMTP id g26FuMfu068151 ; Thu, 7 Mar 2002 00:57:06 +0900 (JST) Message-Id: <200203061557.g26FuMfu068151@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Date: Thu, 07 Mar 2002 00:56:21 +0900 From: Seigo Tanimura To: Matthew Dillon Cc: Seigo Tanimura , Bruce Evans , Terry Lambert , Subject: Re: reclaiming v_data of free vnodes In-Reply-To: <200203051817.g25IHLm71569@apollo.backplane.com> References: <20020305214534.S4601-100000@gamplex.bde.org> <200203051817.g25IHLm71569@apollo.backplane.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002 10:17:21 -0800 (PST), Matthew Dillon said: Matthew> zalloc subsystem cannot shift loads at all and as a consequence we Matthew> already have problems with the system running out of KVM. I have read that the zone allocator of Mach has a gabage collector to reclaim unused free pages. Was that forgotten to port to FreeBSD? -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 8: 2:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 09B1A37B402 for ; Wed, 6 Mar 2002 08:02:47 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g26G2ji84433; Wed, 6 Mar 2002 09:02:46 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g26G2iL84881; Wed, 6 Mar 2002 09:02:45 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 06 Mar 2002 09:02:27 -0700 (MST) Message-Id: <20020306.090227.127359201.imp@village.org> To: rizzo@icir.org Cc: arch@FreeBSD.ORG Subject: Re: do we need full kernel sources to compile loadable modules ? From: "M. Warner Losh" In-Reply-To: <20020305134932.A79697@iguana.icir.org> References: <20020305134932.A79697@iguana.icir.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020305134932.A79697@iguana.icir.org> Luigi Rizzo writes: : Plain and simple... I thought one could compile a kernel extension : (foo.ko) without full kernel sources, as the various include files : describing kernel interfaces and data structures are installed in : various places under /usr/include . : This seems to work fine in many cases. But fails in most cases. : Turns out, however, that at least one thing (namely vnode_if.h) is not : there, and it needs to be reconstructed using sys/kern/vnode_if.{pl,src} Yes. : So i wonder: : : + is it a desirable goal that one can compile kernel extensions without : requiring a full kernel source tree ? No. : + if so, shouldn't we make sure that, as part of the creation of : /usr/include, a copy of vnode_if.h is generated somewhere (maybe : in /usr/include/sys or wherever is more appropriate) ? There's too many of these files. *_if.h from newbus makes this hard. : + are there other header files (and maybe objects, e.g. there is also : a vnode_if.o) which have similar problems ? There are. the *if.h files are the tip of the iceburg last time I tried it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 9:49:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 6F85F37B419; Wed, 6 Mar 2002 09:49:42 -0800 (PST) Received: from pool0158.cvx21-bradley.dialup.earthlink.net ([209.179.192.158] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16ifXj-0004hK-00; Wed, 06 Mar 2002 09:49:36 -0800 Message-ID: <3C86569D.5ECC414E@mindspring.com> Date: Wed, 06 Mar 2002 09:49:17 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: obrien@FreeBSD.ORG, Eivind Eklund , arch@FreeBSD.ORG Subject: Re: do we need full kernel sources to compile loadable modules ? References: <20020305134932.A79697@iguana.icir.org> <20020305230738.C13979@phoenix.dmnshq.net> <20020305145406.A37648@dragon.nuxi.com> <3C85680B.776B76CD@mindspring.com> <20020306003700.A83775@iguana.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > I agree on the comments on the generated files, > I was just asking if we could, as part of the install > of include files, include some rule in the makefile so > that it would generate a copy of vnode_if.h > somewhere in the include tree. The vnode_if.h file is pretty heinous. The problem it's trying to solve is actually the wrong problem to try to solve. The vnode_if.h and vnode_if.c descriptor list is limiting by definition. The original design intent was to permit the addition of descriptor types dynamically. To get to this point, it's pretty imperitive that the descriptor lists be uniquified and sorted. The only way that works to uniquify between two sets of added descriptors vs, the default set is to do it by string name, which is about the only way you can assume a collision space that is non-intersecting. If you consider the case where there is a new VOP, let's call it VOP_TRANSACT, that is supported by two new stacking layers that have to comunicate between an intermediate stacking layer, e.g. a stack of NEW1, nullfs, NEW2, ffs, then the only way to support it is to reinstance the VOP vectors of the existing systems when the new VOPs are added, so that you don't run off the end of the array of vectors in the assembly list when you are calling from NEW1 to NEW2 through the nullfs vector, and so that you get the unsupported VOP when you call from the NEW2 to the ffs layer (a ringing condemnation of the "defaultvops" vector idea, if ever there was one). THe other thing you notice, when you do this, is that in the uniquification process, you end up with a sorted VOP list, and can call directly through the vector, bypassing the reverse lookup-by-descriptor. This takes out two indirections per call through a layer boundary. 8-). Exposing vnode_if.h is a bad idea... because perpetuating a vnode_if.* in the first place is a bad idea. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 10: 7:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 8B23837B400 for ; Wed, 6 Mar 2002 10:07:24 -0800 (PST) Received: from pool0158.cvx21-bradley.dialup.earthlink.net ([209.179.192.158] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16ifoR-0000v4-00; Wed, 06 Mar 2002 10:06:51 -0800 Message-ID: <3C865AAB.BB692A49@mindspring.com> Date: Wed, 06 Mar 2002 10:06:35 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Seigo Tanimura Cc: Matthew Dillon , Bruce Evans , arch@FreeBSD.ORG Subject: Re: reclaiming v_data of free vnodes References: <20020305214534.S4601-100000@gamplex.bde.org> <200203051817.g25IHLm71569@apollo.backplane.com> <200203061557.g26FuMfu068151@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Seigo Tanimura wrote: > On Tue, 5 Mar 2002 10:17:21 -0800 (PST), > Matthew Dillon said: > > Matthew> zalloc subsystem cannot shift loads at all and as a consequence we > Matthew> already have problems with the system running out of KVM. > > I have read that the zone allocator of Mach has a gabage collector to > reclaim unused free pages. Was that forgotten to port to FreeBSD? The FreeeBSD code for the most part has the same API, but in a lot of places, the underlying code is completely different. John made an intentional decision for type stability when he made the semantic "once committed to a zone, always in that zone". Personally, I'd really object to a garbage collector; the one thing you can be sure of with garbage collectors is that they will run at the most inconvenient time possible. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 12: 5:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [65.88.244.127]) by hub.freebsd.org (Postfix) with ESMTP id E285237B416 for ; Wed, 6 Mar 2002 12:05:46 -0800 (PST) Received: from mail.dobox.com ([65.88.244.102] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 16ihfV-000Igp-00 for arch@freebsd.org; Wed, 06 Mar 2002 13:05:46 -0700 Message-ID: <3C862030.9080108@softweyr.com> Date: Wed, 06 Mar 2002 13:57:04 +0000 From: Wes Peters Organization: Softweyr LLC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020222 X-Accept-Language: en-us MIME-Version: 1.0 To: arch@freebsd.org Subject: Sorting and Matching options for ls(1) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At the request of several FreeBSD users, I have developed the following two options for ls(1): -M Display files that match the specified types only. The file types are specified by a single character as in strmode(3), with the option to specify regular files as ``r'' instead of ``-'' if needed. -S Explicity specify the sorting order. The sorting flags are: 0 No sorting. n Sort by filename (default). u File owner user id. g File owner group id. s File size. a File access time (same as -u but does not modify printed output). c File change time (same as -c but does not modify printed output). m File modification time (same as -t but does not modify printed output). t File type, sorted in lexical order as displayed by strmode(3). The -S options change only the sorting order, so it is possible to list the change time while sorting by the access time with: ls -l -c -Sa The code to accomplish both of these adds only 1788 bytes to /bin/ls. The option keyletters S (for Sort) and M (for Match) were carefully chosen to be mnemonic while not conflicting with recent Posix standards or with GNU ls. My current patch against 4.5-RELEASE is available at ftp://softweyr.com/pub/softweyr/ls.diff I plan to create a patch against -CURRENT today or tomorrow. Suggestions, comments, and "don't do thats" all welcome. I hope to achieve enough consensus to commit this in the next few days, as I am going to be quite busy for the next few weeks starting this Sunday. Thank you. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 12:18: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by hub.freebsd.org (Postfix) with ESMTP id F29D137B404 for ; Wed, 6 Mar 2002 12:17:48 -0800 (PST) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.6/8.11.6) id g26KH2g07463; Wed, 6 Mar 2002 20:17:02 GMT (envelope-from rb) Message-Id: <4.3.2.7.2.20020306201110.00c125b0@gid.co.uk> X-Sender: rbmail@gid.co.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Mar 2002 20:16:56 +0000 To: Wes Peters From: Bob Bishop Subject: Re: Sorting and Matching options for ls(1) Cc: arch@FreeBSD.ORG In-Reply-To: <3C862030.9080108@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, At 13:57 06/03/02 +0000, Wes Peters wrote: >At the request of several FreeBSD users, I have developed the following >two options for ls(1): [etc] I have given up flaming for Lent, so I have no opinion about the worth of the proposal :-) :-) However, if you are going to do it, what about b sort by number of blocks allocated (cf ls -s) i sort by inode number (cf ls -i) -- Bob Bishop +44 (0)118 977 4017 rb@gid.co.uk fax +44 (0)118 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 12:18:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 8650137B400 for ; Wed, 6 Mar 2002 12:18:42 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 6389FAE1D0; Wed, 6 Mar 2002 12:18:42 -0800 (PST) Date: Wed, 6 Mar 2002 12:18:42 -0800 From: Alfred Perlstein To: Wes Peters Cc: arch@freebsd.org Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020306201842.GS77980@elvis.mu.org> References: <3C862030.9080108@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C862030.9080108@softweyr.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Wes Peters [020306 12:05] wrote: > At the request of several FreeBSD users, I have developed the following > two options for ls(1): > > -M Display files that match the specified types only. The file > types are specified by a single character as in strmode(3), > with > the option to specify regular files as ``r'' instead of ``-'' > if > needed. > > -S Explicity specify the sorting order. The sorting flags are: EXAMPLES The following is how to do an ls listing sorted by size (and shows why ls does not need a separate option for this): ls -l | sort -n +4 Additionally, the -r flag to sort(1) may be used to get the results sorted from largest to smallest (a reverse sort). -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 12:40:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 1DFFA37B405 for ; Wed, 6 Mar 2002 12:40:52 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA04980; Wed, 6 Mar 2002 13:40:31 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g26KeUd36767; Wed, 6 Mar 2002 13:40:30 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.32446.840336.843194@caddis.yogotech.com> Date: Wed, 6 Mar 2002 13:40:30 -0700 To: Alfred Perlstein Cc: Wes Peters , arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) In-Reply-To: <20020306201842.GS77980@elvis.mu.org> References: <3C862030.9080108@softweyr.com> <20020306201842.GS77980@elvis.mu.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein writes: > * Wes Peters [020306 12:05] wrote: > > At the request of several FreeBSD users, I have developed the following > > two options for ls(1): > > > > -M Display files that match the specified types only. The file > > types are specified by a single character as in strmode(3), > > with > > the option to specify regular files as ``r'' instead of ``-'' > > if > > needed. > > > > -S Explicity specify the sorting order. The sorting flags are: > > EXAMPLES > The following is how to do an ls listing sorted by size (and shows why ls > does not need a separate option for this): > > ls -l | sort -n +4 Or, alternatively. ls -ls | sort And in reverse order ls -ls | sort -r Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 12:56: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [65.88.244.127]) by hub.freebsd.org (Postfix) with ESMTP id ABBB037B400 for ; Wed, 6 Mar 2002 12:56:03 -0800 (PST) Received: from mail.dobox.com ([65.88.244.102] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 16iiRX-000IkC-00; Wed, 06 Mar 2002 13:55:23 -0700 Message-ID: <3C862BD1.3020908@softweyr.com> Date: Wed, 06 Mar 2002 14:46:41 +0000 From: Wes Peters Organization: Softweyr LLC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020222 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Bishop Cc: arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) References: <4.3.2.7.2.20020306201110.00c125b0@gid.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bob Bishop wrote: > Hi, > > At 13:57 06/03/02 +0000, Wes Peters wrote: > >> At the request of several FreeBSD users, I have developed the following >> two options for ls(1): [etc] > > > I have given up flaming for Lent, so I have no opinion about the worth > of the proposal :-) :-) However, if you are going to do it, what about > > b sort by number of blocks allocated (cf ls -s) > > i sort by inode number (cf ls -i) Excellent suggestions. This was such a simple request, I've just finished adding them. I'll update the diff in a few minutes. Thanks! -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 13:11:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id C2ACB37B405 for ; Wed, 6 Mar 2002 13:11:42 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020306211142.NJDL2626.rwcrmhc51.attbi.com@blossom.cjclark.org>; Wed, 6 Mar 2002 21:11:42 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g26LBfF70096; Wed, 6 Mar 2002 13:11:41 -0800 (PST) (envelope-from cjc) Date: Wed, 6 Mar 2002 13:11:41 -0800 From: "Crist J. Clark" To: Wes Peters Cc: arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020306131141.A69228@blossom.cjclark.org> References: <3C862030.9080108@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C862030.9080108@softweyr.com>; from wes@softweyr.com on Wed, Mar 06, 2002 at 01:57:04PM +0000 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Since we're on the topic of ls(1) having too few options, what I'd really like is a switch to print the creation, modified, and access times together. Basically, dumping the whole stat(2) structure would be nice (some other UNIXes have a separate command to do this). -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 13:12:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [65.88.244.127]) by hub.freebsd.org (Postfix) with ESMTP id 1C30B37B400 for ; Wed, 6 Mar 2002 13:12:52 -0800 (PST) Received: from mail.dobox.com ([65.88.244.102] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 16iii2-000IlN-00; Wed, 06 Mar 2002 14:12:27 -0700 Message-ID: <3C862FD0.3040100@softweyr.com> Date: Wed, 06 Mar 2002 15:03:44 +0000 From: Wes Peters Organization: Softweyr LLC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020222 X-Accept-Language: en-us MIME-Version: 1.0 To: Nate Williams Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) References: <3C862030.9080108@softweyr.com> <20020306201842.GS77980@elvis.mu.org> <15494.32446.840336.843194@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > Alfred Perlstein writes: > >>* Wes Peters [020306 12:05] wrote: >> >>>At the request of several FreeBSD users, I have developed the following >>>two options for ls(1): >>> >>> -M Display files that match the specified types only. The file >>> types are specified by a single character as in strmode(3), >>> with >>> the option to specify regular files as ``r'' instead of ``-'' >>> if >>> needed. >>> >>> -S Explicity specify the sorting order. The sorting flags are: >>> >>EXAMPLES >> The following is how to do an ls listing sorted by size (and shows why ls >> does not need a separate option for this): >> >> ls -l | sort -n +4 >> > > Or, alternatively. > > ls -ls | sort > > And in reverse order > > ls -ls | sort -r Now make it do one (or either) and only display the filenames: bash-2.05$ ./ls -Ss /bin tcsh unlink cp test sleep csh rm chmod mkdir echo sh mv cat kill rmail ls red df link sync pax ed chio ln rcp expr realpath hostname ps dd pwd domainname date stty [ rmdir I made all the same arguments to the users who adamantly requested both, and was told resoundingly that resorting to a pipe with combinations of grep, sort, and awk was not acceptable. You could at least assume I know how to read a man page, and use sort and grep. Anyone else who want to raise the trivial argument "ls already has too many options" can simply reply directly to me with a subject of "ls: trivial argument". Spare the list traffic. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 13:27:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 267EC37B405 for ; Wed, 6 Mar 2002 13:27:31 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id E2ACEAE216; Wed, 6 Mar 2002 13:27:30 -0800 (PST) Date: Wed, 6 Mar 2002 13:27:30 -0800 From: Alfred Perlstein To: Wes Peters Cc: Nate Williams , arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020306212730.GT77980@elvis.mu.org> References: <3C862030.9080108@softweyr.com> <20020306201842.GS77980@elvis.mu.org> <15494.32446.840336.843194@caddis.yogotech.com> <3C862FD0.3040100@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C862FD0.3040100@softweyr.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Wes Peters [020306 13:12] wrote: > > Now make it do one (or either) and only display the filenames: > > bash-2.05$ ./ls -Ss /bin fetche le vash! eh? fetche le vash! oh! *boiningingignigng* MOOOOOOOOOO! /bin % ls -l | sort -n +4 | awk '{print $9}' | grep -v '^$' | rs sync kill df stty mv ls rmail link chflags dd rm sh echo ln [ expr unlink csh sleep mkdir test ed rcp tcsh rmdir pwd cat red date hostname realpath chmod getfacl ps domainname chio cp setfacl pax Now.. go away or i shall taunt you a seconnnnnd tim! Yes, this is somewhat ridiculous, I'd agree to add the option now or possibly create another program that does this automagically. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 15: 6:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by hub.freebsd.org (Postfix) with ESMTP id 5AAEF37B404 for ; Wed, 6 Mar 2002 15:06:12 -0800 (PST) Received: from lordtoranga ([24.42.211.99]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.06 201-253-122-122-106-20020109) with ESMTP id <20020306230611.BZSL449426.fep02-mail.bloor.is.net.cable.rogers.com@lordtoranga> for ; Wed, 6 Mar 2002 18:06:11 -0500 Message-ID: <001701c1c563$d1baa9b0$0701a8c0@lordtoranga> From: "Jason Petrie" To: Subject: subscribe freebsd-arch Date: Wed, 6 Mar 2002 18:08:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C1C539.E89B63B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.42.211.99] using ID at Wed, 6 Mar 2002 18:06:10 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C1C539.E89B63B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe freebsd-arch ------=_NextPart_000_0014_01C1C539.E89B63B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

subscribe freebsd-arch

------=_NextPart_000_0014_01C1C539.E89B63B0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 22:43:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id 7683E37B419 for ; Wed, 6 Mar 2002 22:43:16 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g276bIQ78447; Thu, 7 Mar 2002 01:37:18 -0500 (EST) (envelope-from mike) Date: Thu, 7 Mar 2002 01:37:18 -0500 From: Mike Barcroft To: Wes Peters Cc: Nate Williams , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020307013718.D55834@espresso.q9media.com> References: <3C862030.9080108@softweyr.com> <20020306201842.GS77980@elvis.mu.org> <15494.32446.840336.843194@caddis.yogotech.com> <3C862FD0.3040100@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C862FD0.3040100@softweyr.com>; from wes@softweyr.com on Wed, Mar 06, 2002 at 03:03:44PM +0000 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Wes Peters writes: > Now make it do one (or either) and only display the filenames: > > bash-2.05$ ./ls -Ss /bin > tcsh unlink cp test sleep > csh rm chmod mkdir echo > sh mv cat kill rmail > ls red df link sync > pax ed chio ln > rcp expr realpath hostname > ps dd pwd domainname > date stty [ rmdir > > > I made all the same arguments to the users who adamantly requested both, > and was told resoundingly that resorting to a pipe with combinations of > grep, sort, and awk was not acceptable. You could at least assume I know > how to read a man page, and use sort and grep. Now, here's the easy part: add new alias entries to the default .cshrc with new magical ls(1) outputs. There is absolutely no reason to add more functionality, that can be handled with other utilities, to ls(1). The fact that ls(1) does column arranging and N other things is bad enough. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 23: 9:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from bilbo.in.mat.cc (bilbo.in.mat.cc [212.43.217.121]) by hub.freebsd.org (Postfix) with ESMTP id B20C337B402 for ; Wed, 6 Mar 2002 23:09:38 -0800 (PST) Received: from bilbo.org (localhost [127.0.0.1]) by bilbo.in.mat.cc (Postfix) with ESMTP id CDBEC71183; Thu, 7 Mar 2002 08:09:36 +0100 (CET) Received: from sauron (sauron.in.mat.cc [212.43.217.122]) by bilbo.in.mat.cc (Postfix) with ESMTP id F187A71183; Thu, 7 Mar 2002 08:09:32 +0100 (CET) Date: Thu, 07 Mar 2002 08:09:32 +0100 From: Mathieu Arnold To: Wes Peters , arch@freebsd.org Subject: Re: Sorting and Matching options for ls(1) Message-ID: <2064317359.1015488572@sauron> In-Reply-To: <3C862030.9080108@softweyr.com> References: <3C862030.9080108@softweyr.com> X-Mailer: Mulberry/2.2.0b2 (Win32) X-wazaaa: True, true MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --On mercredi 6 mars 2002 13:57 +0000 Wes Peters wrote: > At the request of several FreeBSD users, I have developed the following > two options for ls(1): while we're on ls, I found out yesterday that on a recent linux redhat that when doing just a ls (just file names), it the columns were not larger than the length of the largest file name in it (+3) as in freebsd, all columns are equal : $ ls /bin/ arch cpio false loadkeys ps su ash csh fgrep login pwd sync ash.static cut gawk ls red tar awk date gawk-3.0.6 mail rm tcsh basename dd gettext mkdir rmdir touch bash df grep mknod rpm true bash2 dmesg gtar mktemp rvi umount bsh dnsdomainname gunzip more rview uname cat doexec gzip mount sed usleep chgrp domainname hostname mv setserial vi chmod echo igawk netstat sh view chown ed ipcalc nice sleep vimtutor consolechars egrep kill nisdomainname sort ypdomainname cp ex ln ping stty zcat that's a neat feature I believe, don't you ? -- Mathieu Arnold To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 6 23:15: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id C071337B405 for ; Wed, 6 Mar 2002 23:14:56 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 9D8547830D; Thu, 7 Mar 2002 17:44:54 +1030 (CST) Date: Thu, 7 Mar 2002 17:44:54 +1030 From: Greg Lehey To: Mathieu Arnold Cc: Wes Peters , arch@freebsd.org Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020307174454.J66287@wantadilla.lemis.com> References: <3C862030.9080108@softweyr.com> <2064317359.1015488572@sauron> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2064317359.1015488572@sauron> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday, 7 March 2002 at 8:09:32 +0100, Mathieu Arnold wrote: > > --On mercredi 6 mars 2002 13:57 +0000 Wes Peters wrote: > >> At the request of several FreeBSD users, I have developed the following >> two options for ls(1): > > while we're on ls, I found out yesterday that on a recent linux redhat that > when doing just a ls (just file names), it the columns were not larger than > the length of the largest file name in it (+3) as in freebsd, all columns > are equal : I think what you're saying here is that the columns are of different widths, right, just big enough for the largest file in each of them. > $ ls /bin/ > arch cpio false loadkeys ps su > ash csh fgrep login pwd sync > ash.static cut gawk ls red tar > awk date gawk-3.0.6 mail rm tcsh > basename dd gettext mkdir rmdir touch > bash df grep mknod rpm true > bash2 dmesg gtar mktemp rvi umount > bsh dnsdomainname gunzip more rview uname > cat doexec gzip mount sed usleep > chgrp domainname hostname mv setserial vi > chmod echo igawk netstat sh view > chown ed ipcalc nice sleep vimtutor > consolechars egrep kill nisdomainname sort > ypdomainname The previous two lines were broken by your MUA, right? They weren't intended to make a point about how Red Hat arranges things? > cp ex ln ping stty zcat > > that's a neat feature I believe, don't you ? No, I think it's decidedly untidy. I have to use Red Hat in my Real Job, and I find it one of the many irritating things about it. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 14: 0:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 93D8137B420 for ; Thu, 7 Mar 2002 14:00:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307220014.WMOT1214.rwcrmhc54.attbi.com@InterJet.elischer.org> for ; Thu, 7 Mar 2002 22:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA44126 for ; Thu, 7 Mar 2002 13:44:09 -0800 (PST) Date: Thu, 7 Mar 2002 13:44:08 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Contemplating THIS change to signals. (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Previously sent to -current.. received one +ve response I want a bit more comment before I spend time doing this work.. Does ANYONE have any comments.. If I do this am I going to get Matt'd? (ambushed). There is some behaviour in signals which seems 1/ un-neccesary 2/ potentially dangerous. in addition it is 3/ Definitly incompatible with KSEs. I am hoping that someone can give me a good reason why it is done, and failing that, I'm hoping people can give comments on my thoughts. The behavious in question was inherrited from BSD4.4-LITE2 When the sleep code (tsleep,msleep, cv{stuff}) checks to see if there is a pending signal that might cause the sleep to abort, it calls CURSIG() which calls issignal, which in turn might decide to actually suspend the process. (if the user hit ^Z for example) This is fine when CURSIG is called from userret(), because we are on the user boundary, however calling it from the sleep() call seems a rather UN-NICE thing to do. One could argue that it is safe because you are not allowed to sleep while holding resources (um is it not possible to sleep while holding a vnode?) but it seems that it is possible to hit ^Z at teh right moment while something is holding some resource (during what it expects to be a very short term sleep,) and end up blocking the whole system. I would argue that a process can be considered to be suspended even while it is running in kernel space. My definition of a suspended process would be one that id not running any user code. it is not making any headway on the userland program. This I put it to the group that it is sufficient to only suspend a process when it is crossing the user boundary. (returning to user space) My suggestion is to remove teh code in issignal() that perfoms the blocking actions and create a separate function that does that action. I would then call that function from userret() immediatly after the call to issignal(). The result would be that suspended processes would still not reach userland, but processes would not have to option of suspending indefinitly at sleep(). The signal would still cut short the sleep, but the process would be allowed to proceed to the user boundary, at which point it would be suspended as before. If anyone has any reasons they think this is a bad idea, then please speak up. Neithe Matt (Dillon) nor I can see that stopping in msleep is required, and both of us are in fact un-easy with it. In a THREADED world it gets even more complicated, because the SUSPENDED state is a PER_PROCESS state, which means that you are not suspented until ALL THERADS have left userland and been counted as 'suspended'. Having some threads stopped 'near' msleep and others stopped at the userland boundary is asking for trouble in my opinion. I can not think of any downside to making the suspension (whether from ptrace, or a signal) only occur at the user boundary. If I hear NO arguments I'll take it that no-one can think of any reasons to not change the code. If yuo have a reason PLEASE speak up so that we can discuss it and try figure out whether it is real or can be gotten around in some manner. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 14: 8:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id D98CB37B404 for ; Thu, 7 Mar 2002 14:08:43 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g27M8MnK004411; Thu, 7 Mar 2002 23:08:23 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: Your message of "Thu, 07 Mar 2002 13:44:08 PST." Date: Thu, 07 Mar 2002 23:08:22 +0100 Message-ID: <4410.1015538902@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Ju lian Elischer writes: >I would argue that a process can be considered to be suspended even while >it is running in kernel space. Since this would affect not only SIGSTOP but actually all signals, and since we have long-running syscalls like sendfile I'm not sure this assumption is a good idea. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 14:40:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id EA64237B400 for ; Thu, 7 Mar 2002 14:40:16 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307224016.BUEC2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 22:40:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA44396; Thu, 7 Mar 2002 14:37:20 -0800 (PST) Date: Thu, 7 Mar 2002 14:37:17 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <4410.1015538902@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Poul-Henning Kamp wrote: > In message , Ju > lian Elischer writes: > > >I would argue that a process can be considered to be suspended even while > >it is running in kernel space. > > Since this would affect not only SIGSTOP but actually all signals, > and since we have long-running syscalls like sendfile I'm not sure > this assumption is a good idea. That's the whole point. Only STOP type signals are affected.. the signal delivery process goes as follows: Generally, senders call psignal() psignal() checks if there are IMMEDIATE actions to take. and then puts the signal into the "pending signals" array. One of the things it does is check if it should wake the process. (and also a few other similar checks) In msleep() CURSIG is called. CURSIG calls issignal (indirectly) which checks to see if there are any signals that need to be delivered. If there are, it checks to see if they include a STOP type signal. if so, it suspends the process immediatly. In all other cases, it just returns the fact that a signal is ready, and the system call proceeeds to teh user boundary. At teh user boundary (in userret()), CURSIG is called again but AFTER it is called, postsig() is called. This actually acts out the work needed to DO the signal. In the msleep() case, postsig() is not called after CURSIG() so there is no signal generated at that point, only when it gets back to the user boundary. My suggestion is to stop making STOP type signals an exception, because it should not be necessary to stop them in the middle of a syscall, just stop them from getting back to userspace. I mean, if you are debugging a program and you have stopped it, does it matter to you if it stopped in an msleep in the middle of the system call you are in, or stopped before coming back to you, having completed the system call? There is no difference except that if it didn't have to block it will stop at the user boundary, and if it did block it will stop in a different place. It would be more consistant to have it stop in the same place on each call. In the case of ^Z you are even less interested about exactly WHERE in the syscall yuo stopped as long as you actually stopped. In the case of sendfile, the signal will cut short the syscall in both cases. The differnce is that as it is now it stops in the msleep, and when you release it, it returns to the user boundary and then to the user, and in the new case, it immediatlty retunrs to the user boundary, and on being allowed to continue, goes back to the user. From the user's perspective the two actions are almost indistiguishable. Please let me know if I'm blowing smoke on this! (BTW I say "almost indistiguishable" because there is one minor difference from the user perspective) In a read from a disk file, in the current situation, if the block is in core, you don't block so you stop at the user boundary after having done the copyout(). In the case where it's only on disk, you stop in msleep having NOT YET done the copyout(). In my case, you stop at the user boundary both times, though you haven't done the copyout on the second case either. But in some cases involving multiple reads it is possible that you may find a small amount of difference in the amount of the aborted read gets copied out. before the stop is put into affect. if there has been a partial read, returning to the user boundary may decide to copy out that partial read in some cases (read from tty maybe?) Where it will not have been copied out if you stopped in the msleep. > > -- > 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. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 14:44:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 392DC37B417 for ; Thu, 7 Mar 2002 14:44:36 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g27MiGnK005180; Thu, 7 Mar 2002 23:44:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: Your message of "Thu, 07 Mar 2002 14:37:17 PST." Date: Thu, 07 Mar 2002 23:44:16 +0100 Message-ID: <5179.1015541056@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Ju lian Elischer writes: >My suggestion is to stop making STOP type signals an exception, >because it should not be necessary to stop them in the middle of a >syscall, just stop them from getting back to userspace. I don't agree: we can have very long running syscalls, and being able to stop them may make sense sendfile(), RAID5-rebuilds etc etc. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 15: 0:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 30F3B37B400; Thu, 7 Mar 2002 15:00:24 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307230023.YNGT1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 23:00:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA44494; Thu, 7 Mar 2002 14:52:38 -0800 (PST) Date: Thu, 7 Mar 2002 14:52:36 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Cc: phk@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG oh yes, here is one other way that you can tell the difference between the two cases.. I take this to be a bug :-) Peter's fix a a bandaid to take into account that the STOP type signals are being handled in places other than userret. ---------- Forwarded message ---------- Date: Thu, 07 Mar 2002 11:30:35 +0000 From: Peter Edwards To: Julian Elischer Cc: FreeBSD current users , Mckusick@mckusick.com Subject: Re: Contemplating THIS change to signals. I mentioned something similar for a different reason. Go look at the last part of the following message in the recent -hackers archives: > Subject: ptrace bug? > MessageId: <3C712885.A0A91264@openet-telecom.com> (this was for -stable, BTW) Having the suspend for the ptrace()ing parent done in issignal is a pain when issignal is called multiple times by the debuggee before getting back to userland. The debugger sees wait() return more than once reporting the same signal depending on where the victim process was when it stopped, and the code path back to userland. It's particularly noticable when the ptrace(PT_CONTINUE) tries to continue the process with a signal, and the signal arrives back at the debugger. The debugger has no idea wheather it sees the signal because it tried to send it, or the same signal raised for some other reason. The results of this can be seen in GDB frequently when you use the "signal" command. I suggested moving the ptrace handling to postsig(), but anything along the lines of what you are mentioning seems like an improvement to me, and I'm sure you're much more likely to know what you're doing :-) I only delved in here briefly to try and work out some of the non-obvious behaviour of ptrace(). Oh, and while your mucking with issignal(), any chance of looking at the bug raised (and the patch) in the start of that message, and in PR kern/35175? :-) -- Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 15:36: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id A1DB837B405 for ; Thu, 7 Mar 2002 15:36:00 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA01515; Thu, 7 Mar 2002 16:35:36 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g27NZat02712; Thu, 7 Mar 2002 16:35:36 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.63816.189506.113294@caddis.yogotech.com> Date: Thu, 7 Mar 2002 16:35:36 -0700 To: Julian Elischer Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: References: <4410.1015538902@critter.freebsd.dk> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > My suggestion is to stop making STOP type signals an exception, > because it should not be necessary to stop them in the middle of a > syscall, just stop them from getting back to userspace. What about when you suspend a process in the middle of read/write, which are syscalls? This kind of behavior is *extremely* common-place. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 16:20:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 3E23037B404 for ; Thu, 7 Mar 2002 16:20:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308002009.VVUJ2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 00:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA44948; Thu, 7 Mar 2002 16:06:52 -0800 (PST) Date: Thu, 7 Mar 2002 16:06:52 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <15495.63816.189506.113294@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Nate Williams wrote: > > My suggestion is to stop making STOP type signals an exception, > > because it should not be necessary to stop them in the middle of a > > syscall, just stop them from getting back to userspace. > > What about when you suspend a process in the middle of read/write, which > are syscalls? This kind of behavior is *extremely* common-place hmm can you explain what you mean? I can't think of anything that would change.. > > > > Nate > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 16:20:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id DA10F37B402 for ; Thu, 7 Mar 2002 16:20:20 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308002020.VVYH2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 00:20:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA44946; Thu, 7 Mar 2002 16:05:56 -0800 (PST) Date: Thu, 7 Mar 2002 16:05:55 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <15495.63816.189506.113294@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Nate Williams wrote: > > My suggestion is to stop making STOP type signals an exception, > > because it should not be necessary to stop them in the middle of a > > syscall, just stop them from getting back to userspace. > > What about when you suspend a process in the middle of read/write, which > are syscalls? This kind of behavior is *extremely* common-place. of course The question, is, can you tell the difference between the case where the proces is suspended at the user boundary and where the process is doing it's sleep? (Considering that immediatly after the sleep finishes, it's going to abort the syscall and go to the user boundary because of the signal). > > > > Nate > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 16:25:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 4273F37B425 for ; Thu, 7 Mar 2002 16:24:52 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 1500AAE275; Thu, 7 Mar 2002 16:24:52 -0800 (PST) Date: Thu, 7 Mar 2002 16:24:52 -0800 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <20020308002452.GN26621@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [020307 14:00] wrote: > > My suggestion is to remove teh code in issignal() that perfoms the > blocking actions and create a separate function that does that action. > I would then call that function from userret() immediatly after the call > to issignal(). The result would be that > suspended processes would still not reach userland, but processes would > not have to option of suspending indefinitly at sleep(). You are correct, you can _not_ allow arbitrary kernel threads to block indefinetly while potentially holding higher level locks. Please proceed with your planned work, it seems like the right thing to do. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 16:29:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 882BB37B400 for ; Thu, 7 Mar 2002 16:29:22 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 58813AE211; Thu, 7 Mar 2002 16:29:22 -0800 (PST) Date: Thu, 7 Mar 2002 16:29:22 -0800 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <20020308002922.GO26621@elvis.mu.org> References: <20020308002452.GN26621@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020308002452.GN26621@elvis.mu.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Alfred Perlstein [020307 16:25] wrote: > * Julian Elischer [020307 14:00] wrote: > > > > My suggestion is to remove teh code in issignal() that perfoms the > > blocking actions and create a separate function that does that action. > > I would then call that function from userret() immediatly after the call > > to issignal(). The result would be that > > suspended processes would still not reach userland, but processes would > > not have to option of suspending indefinitly at sleep(). > > You are correct, you can _not_ allow arbitrary kernel threads to > block indefinetly while potentially holding higher level locks. > > Please proceed with your planned work, it seems like the right > thing to do. Both Poul-Henning Kamp and Nate Williams bring up the important point of potentially long running syscalls, there are two ways you might consider fixing this: 1) add an additional flag to msleep to allow suspension during sleep. 2) restart the syscall at the userland boundry. -- -Alfred Perlstein [alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 16:57:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by hub.freebsd.org (Postfix) with ESMTP id D476C37B402 for ; Thu, 7 Mar 2002 16:57:29 -0800 (PST) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g280vJ666244; Thu, 7 Mar 2002 19:57:19 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 7 Mar 2002 19:57:19 -0500 (EST) From: Jeff Roberson To: bright@mu.org Cc: julian@elischer.org, Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: Message-ID: <20020307195241.M64788-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Alfred Perlstein wrote: > > * Alfred Perlstein [020307 16:25] wrote: > > * Julian Elischer [020307 14:00] wrote: > > > > You are correct, you can _not_ allow arbitrary kernel threads to > > block indefinetly while potentially holding higher level locks. > > > > Please proceed with your planned work, it seems like the right > > thing to do. > > Both Poul-Henning Kamp and Nate Williams bring up the important > point of potentially long running syscalls, there are two > ways you might consider fixing this: > > 1) add an additional flag to msleep to allow suspension during sleep. > 2) restart the syscall at the userland boundry. > Wouldn't it be reasonable to ignore the stop until we return to the user? This way we could continue to honor all other signals inside msleep, which seems to be very desirable. We should just postpone the STOP until we actually return to the user. Am I missing something? Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 17:11:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id B76CA37B405 for ; Thu, 7 Mar 2002 17:11:07 -0800 (PST) Received: from pool0078.cvx21-bradley.dialup.earthlink.net ([209.179.192.78] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j8uI-0000Mw-00; Thu, 07 Mar 2002 17:10:50 -0800 Message-ID: <3C880F87.62D81504@mindspring.com> Date: Thu, 07 Mar 2002 17:10:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > > My suggestion is to stop making STOP type signals an exception, > > > because it should not be necessary to stop them in the middle of a > > > syscall, just stop them from getting back to userspace. > > > > What about when you suspend a process in the middle of read/write, which > > are syscalls? This kind of behavior is *extremely* common-place. > > of course > The question, is, can you tell the difference between the case where > the proces is suspended at the user boundary and where > the process is doing it's sleep? (Considering that immediatly after the > sleep finishes, it's going to abort the syscall and go to the user > boundary because of the signal). Put this way, it's the correct thing to do, if it makes life easier for the KSE stuff. It wasn't clear to me that you were actually aborting the call, rather than allowing it to run to completion, and then delivering the signal, at least from your text description... It also wasn't clear to me that the patch did what you say it does. In particular, I wondered if it did the right thing in the system call restart case (SA_RESTART in the sa_flags). It would be real annoying to be almost done with something, and have to restart it, and it would be equally annoying to be partially done with a write, and have it interrupted, leaving the written object in an indeterminate state. If you can vouch for the SA_RESTART case, and for the case that Nate contemplated (long running call suspended and restarted, rather than interrupted), then it passes the filters I care about. Nate probably cares more about the "suspend long call in the middle, with the intent to resume, but the resume is interrupted, and never happens" case for things like sendfile. I think the problem there is that it results in the state of the connection being indeterminate, so it is hard or impossible to pick up in the middle in the restart case, and guarantee that the data sent down the connection isn't duplicated/omitted. In other words, an HTTP client in an indeterminate state getting a sendfile from a server could make it so that the server has to know to abandon the connection, where with the current code, it can pick up where it left off. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 17:24:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id A107D37B416 for ; Thu, 7 Mar 2002 17:24:48 -0800 (PST) Received: from pool0078.cvx21-bradley.dialup.earthlink.net ([209.179.192.78] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j97b-00032l-00; Thu, 07 Mar 2002 17:24:36 -0800 Message-ID: <3C8812C0.DE9060FB@mindspring.com> Date: Thu, 07 Mar 2002 17:24:16 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Roberson Cc: bright@mu.org, julian@elischer.org, arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) References: <20020307195241.M64788-100000@mail.chesapeake.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jeff Roberson wrote: > > Both Poul-Henning Kamp and Nate Williams bring up the important > > point of potentially long running syscalls, there are two > > ways you might consider fixing this: > > > > 1) add an additional flag to msleep to allow suspension during sleep. > > 2) restart the syscall at the userland boundry. > > Wouldn't it be reasonable to ignore the stop until we return to the user? > This way we could continue to honor all other signals inside msleep, which > seems to be very desirable. We should just postpone the STOP until we > actually return to the user. > > Am I missing something? A long running system call is supposedly signallable; in the STOP case, this implies that it pauses operation ubtil a CONT or a subsequent interrupt. As Julian has noted, "STOP" is a special case. Doing it your way, you would continue to send data on a "sendfile" operation; doing it the old way, the operation is suspended. In theory, according to the most recent postings by Julian, Julian's change will not modify the behaviour. But instead will cause the run-up to the user boundary, instead of in the middle of wherever the signal was delivered. For things like STOP, this means that it will run up to the user boundary. I'm not sure this is right, if there is a subsequent CONT; for an interrupt, Julian is correct that there is no visible difference in running it up to the user boundary, vs. doing a wakeup as a result, and later scheduling the runnning up to the user boundary; see my prior posting, and Nate's prior posting. Julian's point is that this will make things easier for the KSE work. THis is because it can use a KSE context to do the run up to the user boundary, rather than having to be a special case, where the processor continues the next time the process is scheduled (in this case the KSE), to do the runnning up then. The benefit to doing this for the KSE case should be obvious: it decouples the scheduling from the KSE itself having to run to completion (or at least the user boundary). This means that the priority for the signal delivery can be arbitrated by the user threads scheduler, which gives it more control than it would have otherwise, and saves some masking and unmasking. I'm personally really leery of changes in this area, since I expect at some time that there will be desire to support POSIX queued signals as part of the RT POSIX extensions (a recent discussion about signal delivery in aio completion events indicates that this may be an immediate need for an application being ported from Linux). I'm also a little bit leery, since by the same argument that Julian is using, signals can be delivered to user space in the KSE case, to be dispatched by the user threads scheduler. THis gets rid of all the masking and unmasking, and the associated protection domain crossing that happens currently in the user space threads library (in fact, you could do this in the current user space threads library by establishing a handler for all signals that's sole purpose was to reflect the signals into a user space signal dispatcher; this would make the user space threads significantly lighter weight, even without the KSE changes). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 17:51:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 12D8C37B404 for ; Thu, 7 Mar 2002 17:51:54 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id CBF80AE1FC; Thu, 7 Mar 2002 17:51:53 -0800 (PST) Date: Thu, 7 Mar 2002 17:51:53 -0800 From: Alfred Perlstein To: Jeff Roberson Cc: julian@elischer.org, arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <20020308015153.GP26621@elvis.mu.org> References: <20020307195241.M64788-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020307195241.M64788-100000@mail.chesapeake.net> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Jeff Roberson [020307 16:57] wrote: > > > On Thu, 7 Mar 2002, Alfred Perlstein wrote: > > > > > * Alfred Perlstein [020307 16:25] wrote: > > > * Julian Elischer [020307 14:00] wrote: > > > > > > You are correct, you can _not_ allow arbitrary kernel threads to > > > block indefinetly while potentially holding higher level locks. > > > > > > Please proceed with your planned work, it seems like the right > > > thing to do. > > > > Both Poul-Henning Kamp and Nate Williams bring up the important > > point of potentially long running syscalls, there are two > > ways you might consider fixing this: > > > > 1) add an additional flag to msleep to allow suspension during sleep. > > 2) restart the syscall at the userland boundry. > > > > Wouldn't it be reasonable to ignore the stop until we return to the user? > This way we could continue to honor all other signals inside msleep, which > seems to be very desirable. We should just postpone the STOP until we > actually return to the user. > > Am I missing something? This is a good idea however you are missing something. We need to be able to unpost the STOP then that way when if while blocked in tsleep a STOP followed by a CONT is delivered we don't get the ordering wrong, either that or the underlying issig (or whatever) needs to make sure it processes STOPs before CONTs. I think at this point we should be looking at code and/or giving Julian some time to think about alternatives and the pitfalls of just waiting for the userret boundry. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 18: 0:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 2525137B416 for ; Thu, 7 Mar 2002 18:00:19 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308020018.LWQZ1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 02:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA45398; Thu, 7 Mar 2002 17:54:23 -0800 (PST) Date: Thu, 7 Mar 2002 17:54:21 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <20020308002922.GO26621@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Alfred Perlstein wrote: > * Alfred Perlstein [020307 16:25] wrote: > > * Julian Elischer [020307 14:00] wrote: > > > > > > My suggestion is to remove teh code in issignal() that perfoms the > > > blocking actions and create a separate function that does that action. > > > I would then call that function from userret() immediatly after the call > > > to issignal(). The result would be that > > > suspended processes would still not reach userland, but processes would > > > not have to option of suspending indefinitly at sleep(). > > > > You are correct, you can _not_ allow arbitrary kernel threads to > > block indefinetly while potentially holding higher level locks. > > > > Please proceed with your planned work, it seems like the right > > thing to do. > > Both Poul-Henning Kamp and Nate Williams bring up the important > point of potentially long running syscalls, there are two > ways you might consider fixing this: > > 1) add an additional flag to msleep to allow suspension during sleep. > 2) restart the syscall at the userland boundry. Long running system calls behave the same. If the sleep in uninterruptable then in neither case is there a change. IF it's interruptable then either it suspends in the sleep and then immediatly heads for the user boundary. or it heads for the user boundary and suspends. Either way it looks the same from the outside.. it doesn't return to user space until the suspension is lifted. > > -- > -Alfred Perlstein [alfred@freebsd.org] > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 18: 0:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 9258537B400 for ; Thu, 7 Mar 2002 18:00:23 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308020020.LWRS1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 02:00:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA45418; Thu, 7 Mar 2002 17:59:17 -0800 (PST) Date: Thu, 7 Mar 2002 17:59:17 -0800 (PST) From: Julian Elischer To: Jeff Roberson Cc: bright@mu.org, arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <20020307195241.M64788-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Jeff Roberson wrote: > > > On Thu, 7 Mar 2002, Alfred Perlstein wrote: > > > > > * Alfred Perlstein [020307 16:25] wrote: > > > * Julian Elischer [020307 14:00] wrote: > > > > > > You are correct, you can _not_ allow arbitrary kernel threads to > > > block indefinetly while potentially holding higher level locks. > > > > > > Please proceed with your planned work, it seems like the right > > > thing to do. > > > > Both Poul-Henning Kamp and Nate Williams bring up the important > > point of potentially long running syscalls, there are two > > ways you might consider fixing this: > > > > 1) add an additional flag to msleep to allow suspension during sleep. > > 2) restart the syscall at the userland boundry. > > > > Wouldn't it be reasonable to ignore the stop until we return to the user? > This way we could continue to honor all other signals inside msleep, which > seems to be very desirable. We should just postpone the STOP until we > actually return to the user. That's basically what I want to do. set a flag saying "We've been stopped" and leave. When we get to teh user boundary we stop if it's set. not too hard really. > > Am I missing something? I don't thinksoi, but that's why I'm asking.. Im also hoping to hear from kirk since we inherritted this behaviour from 4.4lite2 > > Jeff > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 18:20:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 029EC37B47D for ; Thu, 7 Mar 2002 18:20:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308022009.FMJG1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 02:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA45543; Thu, 7 Mar 2002 18:14:32 -0800 (PST) Date: Thu, 7 Mar 2002 18:14:31 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <3C880F87.62D81504@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Terry Lambert wrote: > Julian Elischer wrote: > > > > My suggestion is to stop making STOP type signals an exception, > > > > because it should not be necessary to stop them in the middle of a > > > > syscall, just stop them from getting back to userspace. > > > > > > What about when you suspend a process in the middle of read/write, which > > > are syscalls? This kind of behavior is *extremely* common-place. > > > > of course > > The question, is, can you tell the difference between the case where > > the proces is suspended at the user boundary and where > > the process is doing it's sleep? (Considering that immediatly after the > > sleep finishes, it's going to abort the syscall and go to the user > > boundary because of the signal). > > Put this way, it's the correct thing to do, if it makes > life easier for the KSE stuff. > > It wasn't clear to me that you were actually aborting the > call, rather than allowing it to run to completion, and > then delivering the signal, at least from your text > description... I don't abort the sleep if it's not interruptable. I just done STOP there if I do get a signal. I am a littel worried about sendfile. That system call is so different from the rest of the world that it may need special handling. If you STOP a process at the moment that is sending a 2MB file out a socket, then the transmission stops and the sleep will abort if SB_NOINR is not set. I can't see where it is set so I suspect that it will abort out and come to the user boundary and then restart, but I haven't proved that yet. In that case it would behave about the same with the change as without it. > > It also wasn't clear to me that the patch did what you say > it does. In particular, I wondered if it did the right > thing in the system call restart case (SA_RESTART in the > sa_flags). It would be real annoying to be almost done > with something, and have to restart it, and it would be > equally annoying to be partially done with a write, and > have it interrupted, leaving the written object in an > indeterminate state. Don't forget that many syscalls handle SA_RESTART so that yuo keep getting more data so that in teh end you can't tell the difference. > > If you can vouch for the SA_RESTART case, and for the case > that Nate contemplated (long running call suspended and > restarted, rather than interrupted), then it passes the > filters I care about. > > Nate probably cares more about the "suspend long call in > the middle, with the intent to resume, but the resume is > interrupted, and never happens" case for things like > sendfile. I think the problem there is that it results > in the state of the connection being indeterminate, so it > is hard or impossible to pick up in the middle in the > restart case, and guarantee that the data sent down the > connection isn't duplicated/omitted. In other words, an > HTTP client in an indeterminate state getting a sendfile > from a server could make it so that the server has to > know to abandon the connection, where with the current > code, it can pick up where it left off. I believe so, but have not yet proved it. > > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 18:34:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2ADFF37B402 for ; Thu, 7 Mar 2002 18:34:36 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g282YPD38378; Thu, 7 Mar 2002 21:34:25 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 7 Mar 2002 21:34:25 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Julian Elischer wrote: > When the sleep code (tsleep,msleep, cv{stuff}) checks to see if there > is a pending signal that might cause the sleep to abort, it calls > CURSIG() which calls issignal, which in turn might decide to actually > suspend the process. (if the user hit ^Z for example) Eww. That sounds bad for all the reasons you identify. > One could argue that it is safe because you are not allowed to sleep > while holding resources (um is it not possible to sleep while holding a > vnode?) but it seems that it is possible to hit ^Z at teh right moment > while something is holding some resource (during what it expects to be a > very short term sleep,) and end up blocking the whole system. That sounds like a reasonable argument to me. > I would argue that a process can be considered to be suspended even > while it is running in kernel space. My definition of a suspended > process would be one that id not running any user code. it is not making > any headway on the userland program. This I put it to the group that it > is sufficient to only suspend a process when it is crossing the user > boundary. (returning to user space) Sounds good. Asserting that the STOP state only affects a process when executing in userland makes sense to me. Question: how will this impact shells that suspend a child process--do they generally restore control to the user immediately, or wait for it to "succeed" somehow? Will it now be the case that hitting Ctrl-Z for an application using sendfile() will not take affect until the file is sent? > My suggestion is to remove teh code in issignal() that perfoms the > blocking actions and create a separate function that does that action. I > would then call that function from userret() immediatly after the call > to issignal(). The result would be that suspended processes would still > not reach userland, but processes would not have to option of suspending > indefinitly at sleep(). Sounds good. A recipe for deadlock, otherwise. > If anyone has any reasons they think this is a bad idea, then please > speak up. Neithe Matt (Dillon) nor I can see that stopping in msleep is > required, and both of us are in fact un-easy with it. > > In a THREADED world it gets even more complicated, because the SUSPENDED > state is a PER_PROCESS state, which means that you are not suspented > until ALL THERADS have left userland and been counted as 'suspended'. > Having some threads stopped 'near' msleep and others stopped at the > userland boundary is asking for trouble in my opinion. Sounds right. One of the nice things about KSE is that it allows us to not have to deal with many threading issues, leaving that to the userland thread library. For example, we can assert that a process go down to one kernel thread of execution with no parallelism before calling fork() or exec(), and leave it up to the userland library how it gets there if it wants to do it cleanly. > I can not think of any downside to making the suspension (whether from > ptrace, or a signal) only occur at the user boundary. The only question I have is the one mentioned above -- what weird impacts, if any, this would have on expected shell behavior. > If I hear NO arguments I'll take it that no-one can think of any reasons > to not change the code. If yuo have a reason PLEASE speak up so that we > can discuss it and try figure out whether it is real or can be gotten > around in some manner. Generally sounds good. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 20: 2:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 8E5B837B41B for ; Thu, 7 Mar 2002 20:02:12 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id VAA12346; Thu, 7 Mar 2002 21:02:08 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g28428J04624; Thu, 7 Mar 2002 21:02:08 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15496.14272.351722.199146@caddis.yogotech.com> Date: Thu, 7 Mar 2002 21:02:08 -0700 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: References: <15495.63816.189506.113294@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > My suggestion is to stop making STOP type signals an exception, > > > because it should not be necessary to stop them in the middle of a > > > syscall, just stop them from getting back to userspace. > > > > What about when you suspend a process in the middle of read/write, which > > are syscalls? This kind of behavior is *extremely* common-place > > hmm can you explain what you mean? I can't think of anything > that would change.. 'read' is a system call. If a program is sitting in a read (waiting for user input), this system call must be interruptible. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 20: 3:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E601D37B400 for ; Thu, 7 Mar 2002 20:03:26 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id VAA12402; Thu, 7 Mar 2002 21:03:23 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g2843NC04644; Thu, 7 Mar 2002 21:03:23 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15496.14346.988827.915384@caddis.yogotech.com> Date: Thu, 7 Mar 2002 21:03:22 -0700 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: References: <15495.63816.189506.113294@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > My suggestion is to stop making STOP type signals an exception, > > > because it should not be necessary to stop them in the middle of a > > > syscall, just stop them from getting back to userspace. > > > > What about when you suspend a process in the middle of read/write, which > > are syscalls? This kind of behavior is *extremely* common-place. > > > The question, is, can you tell the difference between the case where > the proces is suspended at the user boundary and where > the process is doing it's sleep? How are you going to 'interrupt' the system call without interrupting the system call? Maybe I'm misunderstanding, but it sounds like you are proposing that no system calls need to be interruptable. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 22:20:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id E6C4B37B400 for ; Thu, 7 Mar 2002 22:20:23 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308062023.HWHM2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 06:20:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA46387; Thu, 7 Mar 2002 22:08:49 -0800 (PST) Date: Thu, 7 Mar 2002 22:08:49 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <15496.14346.988827.915384@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG SIGSTOP doesn't interrupt the system call. it behaves differently. it moves if from the temporary (maybe) sleep to a permanent (until CONT arrives) SUSPENDED state, but never interrupts it. On Thu, 7 Mar 2002, Nate Williams wrote: > > > > My suggestion is to stop making STOP type signals an exception, > > > > because it should not be necessary to stop them in the middle of a > > > > syscall, just stop them from getting back to userspace. > > > > > > What about when you suspend a process in the middle of read/write, which > > > are syscalls? This kind of behavior is *extremely* common-place. > > > > > > The question, is, can you tell the difference between the case where > > the proces is suspended at the user boundary and where > > the process is doing it's sleep? > > How are you going to 'interrupt' the system call without interrupting > the system call? Maybe I'm misunderstanding, but it sounds like you > are proposing that no system calls need to be interruptable. > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 22:20:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 6820737B402 for ; Thu, 7 Mar 2002 22:20:35 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308062034.HWKC2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 06:20:34 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA46385; Thu, 7 Mar 2002 22:06:26 -0800 (PST) Date: Thu, 7 Mar 2002 22:06:25 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <15496.14272.351722.199146@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Nate Williams wrote: > > > > My suggestion is to stop making STOP type signals an exception, > > > > because it should not be necessary to stop them in the middle of a > > > > syscall, just stop them from getting back to userspace. > > > > > > What about when you suspend a process in the middle of read/write, which > > > are syscalls? This kind of behavior is *extremely* common-place > > > > hmm can you explain what you mean? I can't think of anything > > that would change.. > > 'read' is a system call. If a program is sitting in a read (waiting for > user input), this system call must be interruptible. > or not, either way it doesn't matter. The important thing is that no matter what happens it doesn't return to the user while the user is suspended. currently: If the sleep is interruptable (PCATCH) then the code will receive the STOP. It will not wake up, but transition into the STOPPED state (the timer keeps running however). When the timer terminates, or the data arrives it attempts to wake up the process, but noticing it is STOPPED, doesn't actually put it on the run queue. Later when the CONT is received, it is put on the run queue, reads the data (or not) and returns to user mode. Until CONT is received it is holding resources etc. If the CONT happens before the data arrives or the timeout expires the process is put back into SLEEP mode.. When the data arrives or the timeout happens, it doesn't notice it was STOPPED before. My suggestion: If the sleep is interruptable (PCATCH), a flag is set saying a STOP was seen, no other action. When the data arrives or the timeout expires, it reads the data (or not) and proceeds to the user boundary. It waits there for the CONT signal. If the CONT happens before the data arrives or the timeout expires the flag is simply cleared again. It doesn't make such a huge difference now but when there are multiple threads in a process, being able to report to the controlling shell, or the debugger "OK its STOPPED" as soon as I can prove that all threads are in the kernel and not in user space makes a big difference. Also, the bit for "this process is STOPPING" can be set by another thread and all threads will see it. Saving me from having to run around all threads and do all sorts of stuff with each. I don't necessarily want to do this in -current on it's own. I have code that does this in the KSE diffs. I want to know if I've forgotten anything because when I commit the KSE diffs I don;t want to discover I've broken everything. it ispossible I might be able to commit this change separatly before hand so that it's an Isolated change however and if I can I might think about doing that. That way we introduce one change at a time. > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 22:25:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id F3B7137B416 for ; Thu, 7 Mar 2002 22:25:15 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id XAA18016; Thu, 7 Mar 2002 23:25:12 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g286P6306706; Thu, 7 Mar 2002 23:25:07 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15496.22850.811384.136422@caddis.yogotech.com> Date: Thu, 7 Mar 2002 23:25:06 -0700 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: References: <15496.14346.988827.915384@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > SIGSTOP doesn't interrupt the system call. Sure it does. The system call does one of two things. 1) Prematurely exits, but allows itself to be re-started automatically upon reciept of SIGCONT *or* 2) Completes, but has a return value such that the userland program can re-start the system call again. In both cases, it has been 'interrupted' (it did not complete as it would had it not received a SIGSTOP signal). > it moves if from the temporary (maybe) sleep to a permanent (until > CONT arrives) SUSPENDED state, but never interrupts it. Now we're arguing semantics. We must allow the program the ability to return control back to the userland, and not stay in the kernel. > > > On Thu, 7 Mar 2002, Nate Williams wrote: > > > > > > My suggestion is to stop making STOP type signals an exception, > > > > > because it should not be necessary to stop them in the middle of a > > > > > syscall, just stop them from getting back to userspace. > > > > > > > > What about when you suspend a process in the middle of read/write, which > > > > are syscalls? This kind of behavior is *extremely* common-place. > > > > > > > > > The question, is, can you tell the difference between the case where > > > the proces is suspended at the user boundary and where > > > the process is doing it's sleep? > > > > How are you going to 'interrupt' the system call without interrupting > > the system call? Maybe I'm misunderstanding, but it sounds like you > > are proposing that no system calls need to be interruptable. > > > > > > Nate > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 22:36:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4BE3537B402 for ; Thu, 7 Mar 2002 22:36:13 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id XAA18482; Thu, 7 Mar 2002 23:36:09 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g286a4C06813; Thu, 7 Mar 2002 23:36:04 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15496.23508.148366.980354@caddis.yogotech.com> Date: Thu, 7 Mar 2002 23:36:04 -0700 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: References: <15496.14272.351722.199146@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > > My suggestion is to stop making STOP type signals an exception, > > > > > because it should not be necessary to stop them in the middle of a > > > > > syscall, just stop them from getting back to userspace. > > > > > > > > What about when you suspend a process in the middle of read/write, which > > > > are syscalls? This kind of behavior is *extremely* common-place > > > > > > hmm can you explain what you mean? I can't think of anything > > > that would change.. > > > > 'read' is a system call. If a program is sitting in a read (waiting for > > user input), this system call must be interruptible. > > > > or not, either way it doesn't matter. > > The important thing is that no matter what happens it doesn't return to > the user while the user is suspended. However, control is returned to the parent process (such as the shell), correct? Something is returning to userland. > currently: If the sleep is interruptable (PCATCH) then the code will > receive the STOP. It will not wake up, but transition into the STOPPED > state (the timer keeps running however). I'm with you so far. (Although stating the 'the timer keeps running' is misleading, since the 'timer' isn't created on a per-process basis). > When the timer terminates, or the > data arrives it attempts to wake up the process, but noticing it is > STOPPED, doesn't actually put it on the run queue. Later when the CONT is > received, it is put on the run queue, reads the data (or not) and returns > to user mode. Still with you. > Until CONT is received it is holding resources etc. Hopefully not. :) > If the > CONT happens before the data arrives or the timeout expires the process is > put back into SLEEP mode.. When the data arrives or the timeout happens, > it doesn't notice it was STOPPED before. Exactly. > My suggestion: If the sleep is interruptable (PCATCH), a flag is set > saying a STOP was seen, no other action. When the data arrives or the > timeout expires, it reads the data (or not) and proceeds to the user > boundary. In effect, the context is actually still active inside the kernel, even though the userland process is never given notice. I could see this having *really* strange effects for things that do network I/O. Often-times I've suspended processes inside of gdb so I could set breakpoints knowing full well that *NOTHING* was going to happen, even if I was in the middle of a system call. I'm still not getting a warm fuzzy that allowing the userland context to complete and then block at the userland boundary is a good idea. I'm not saying it's a bad idea, but I'm almost positive there are gremlins hiding in the details here. :) > It waits there for the CONT signal. If the CONT happens before > the data arrives or the timeout expires the flag is simply cleared again. In effect, you're avoiding moving the process from the STOPPED queue and back to the SLEEP queue. > It doesn't make such a huge difference now but when there are multiple > threads in a process, being able to report to the controlling shell, > or the debugger "OK its STOPPED" as soon as I can prove that all > threads are in the kernel and not in user space makes a big > difference. Right, but currently, stopping a process/thread stops it *everywhere*, including the kernel. We're changing something that has been done this way for a very long time, and the POLA may come back and bite us. > Also, the bit for "this process is STOPPING" can be set by another > thread and all threads will see it. Saving me from having to run > around all threads and do all sorts of stuff with each. Except that there are now locking issues since the 'other thread' is now messing around with parts of the thread that may be in use by the thread itself. (*ick*) > I don't necessarily want to do this in -current on it's own. I have > code that does this in the KSE diffs. I want to know if I've forgotten > anything because when I commit the KSE diffs I don;t want to discover > I've broken everything. I'm sure you have, but probably not intentionally. There is almost certainly software that relies on the existing behavior, and will behave differently (perhaps not wrong) with the aboved described changes. > it ispossible I might be able to > commit this change separatly before hand so that it's an Isolated change > however and if I can I might think about doing that. Maybe a sysctl to turn it off/on? However, I suspect this would be *really* hard to keep both ways going. Thanks for the more detailed explanation!! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 7 23:55:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sharmas.dhs.org (cpe-66-1-147-119.ca.sprintbbd.net [66.1.147.119]) by hub.freebsd.org (Postfix) with ESMTP id 02D7637B402 for ; Thu, 7 Mar 2002 23:55:32 -0800 (PST) Received: by sharmas.dhs.org (Postfix, from userid 500) id 149325E6FA; Fri, 8 Mar 2002 00:01:01 -0800 (PST) Date: Fri, 8 Mar 2002 00:01:01 -0800 From: Arun Sharma To: arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020308080100.GA26403@sharma-home.net> References: <3C862030.9080108@softweyr.com> <20020306131141.A69228@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020306131141.A69228@blossom.cjclark.org> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 01:11:41PM -0800, Crist J. Clark wrote: > Since we're on the topic of ls(1) having too few options, what I'd > really like is a switch to print the creation, modified, and access > times together. FreeBSD stores the file creation time ? ctime stands for change time, not creation time. I don't mind having FreeBSD store the file creation time though :) -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 0:20:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 8DAED37B405 for ; Fri, 8 Mar 2002 00:20:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308082015.JKZI2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 08:20:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA46936; Fri, 8 Mar 2002 00:08:51 -0800 (PST) Date: Fri, 8 Mar 2002 00:08:49 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <15496.22850.811384.136422@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Nate Williams wrote: We're talking about a STOP received while (or before) the syscall blocks in a sleep(). > > SIGSTOP doesn't interrupt the system call. > > Sure it does. The system call does one of two things. > > 1) Prematurely exits, but allows itself to be re-started automatically > upon reciept of SIGCONT No, it is not really interrupted. It has not been sent back to the userland. A STOP certainly doesn't prematurely kill it. Its stack still says that it is in the sleep. If the SIGCONT occurs, it is still in the sleep where it was before an if not, the timeout timer is still running.. An interrupted sleep is when the timeout is cancelled and control is returned so that it goes back towards the userland. This does not happen in a syscall when a SIGSTOP is received. > *or* > 2) Completes, but has a return value such that the userland program can > re-start the system call again. This is never the result of a STOP signal detected in msleep(tsleep) > > In both cases, it has been 'interrupted' (it did not complete as it > would had it not received a SIGSTOP signal). SIGSTOP does not do this (unless you have set a signal handler for it in which ccase it is no longer SIGSTOP but rather something else (in fact CAN you set a SIGSTOP handler?) > > > it moves if from the temporary (maybe) sleep to a permanent (until > > CONT arrives) SUSPENDED state, but never interrupts it. > > Now we're arguing semantics. We must allow the program the ability to > return control back to the userland, and not stay in the kernel. SIGSTOP doesn't do that. > > > > > > > On Thu, 7 Mar 2002, Nate Williams wrote: > > > > > > > > My suggestion is to stop making STOP type signals an exception, > > > > > > because it should not be necessary to stop them in the middle of a > > > > > > syscall, just stop them from getting back to userspace. > > > > > > > > > > What about when you suspend a process in the middle of read/write, which > > > > > are syscalls? This kind of behavior is *extremely* common-place. > > > > > > > > > > > > The question, is, can you tell the difference between the case where > > > > the proces is suspended at the user boundary and where > > > > the process is doing it's sleep? > > > > > > How are you going to 'interrupt' the system call without interrupting > > > the system call? Maybe I'm misunderstanding, but it sounds like you > > > are proposing that no system calls need to be interruptable. > > > > > > > > > Nate > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 0:25:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by hub.freebsd.org (Postfix) with ESMTP id 16BC737B402 for ; Fri, 8 Mar 2002 00:25:29 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.35 #1 (Debian)) id 16jFgV-0001kC-00; Fri, 08 Mar 2002 00:25:03 -0800 Date: Fri, 8 Mar 2002 00:25:03 -0800 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <20020308082503.GA6690@gnuppy.monkey.org> References: <15496.22850.811384.136422@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i From: Bill Huey Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 08, 2002 at 12:08:49AM -0800, Julian Elischer wrote: > No, it is not really interrupted. It has not been sent back to the > userland. A STOP certainly doesn't prematurely kill it. > Its stack still says that it is in the sleep. > If the SIGCONT occurs, it is still in the sleep where it was before > an if not, the timeout timer is still running.. > > An interrupted sleep is when the timeout is cancelled and control is > returned so that it goes back towards the userland. This does not > happen in a syscall when a SIGSTOP is received. The way I read it was that both of those things are a kind of notification to that system call and not literally an interrupt that absolutely must return it back to userspace some how. > > 2) Completes, but has a return value such that the userland program can > > re-start the system call again. > > This is never the result of a STOP signal detected in msleep(tsleep) > > In both cases, it has been 'interrupted' (it did not complete as it > > would had it not received a SIGSTOP signal). > > SIGSTOP does not do this (unless you have set a signal handler for it > in which ccase it is no longer SIGSTOP but rather something else > (in fact CAN you set a SIGSTOP handler?) Don't remember, signals are evil. ;) bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 0:40:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id A8AF637B402 for ; Fri, 8 Mar 2002 00:40:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308084013.JPVE2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 08:40:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA47019; Fri, 8 Mar 2002 00:34:18 -0800 (PST) Date: Fri, 8 Mar 2002 00:34:16 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <15496.23508.148366.980354@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Nate Williams wrote: > > > > or not, either way it doesn't matter. > > > > The important thing is that no matter what happens it doesn't return to > > the user while the user is suspended. > > However, control is returned to the parent process (such as the shell), > correct? Something is returning to userland. A signal. at the time that the process has it's "Im stopped' bit set. (and wait() returns if you did one) > > > currently: If the sleep is interruptable (PCATCH) then the code will > > receive the STOP. It will not wake up, but transition into the STOPPED > > state (the timer keeps running however). This is when the signal is sent. > > I'm with you so far. (Although stating the 'the timer keeps running' is > misleading, since the 'timer' isn't created on a per-process basis). There is a timeout entry for it ok? > > > When the timer terminates, or the > > data arrives it attempts to wake up the process, but noticing it is > > STOPPED, doesn't actually put it on the run queue. Later when the CONT is > > received, it is put on the run queue, reads the data (or not) and returns > > to user mode. > > Still with you. > > > Until CONT is received it is holding resources etc. > > Hopefully not. :) Hopefully not contentious resources but still some resorces, (e.g. anything it malloc'd on the way in). > > > If the > > CONT happens before the data arrives or the timeout expires the process is > > put back into SLEEP mode.. When the data arrives or the timeout happens, > > it doesn't notice it was STOPPED before. > > Exactly. > > > My suggestion: If the sleep is interruptable (PCATCH), a flag is set > > saying a STOP was seen, no other action. When the data arrives or the > > timeout expires, it reads the data (or not) and proceeds to the user > > boundary. When I say "no other action" I don't include sending the signal which still happens (to the parent). > > In effect, the context is actually still active inside the kernel, even > though the userland process is never given notice. I could see this > having *really* strange effects for things that do network I/O. > Often-times I've suspended processes inside of gdb so I could set > breakpoints knowing full well that *NOTHING* was going to happen, even > if I was in the middle of a system call. You'd be surprised then because once the send() is done, the network IO will happen independently of the process. this is no different. from the time you do the ^Z to the time the syscall thinks of returning is how long? If you say 3 seconds then all that is different is that in my case the data has been taken off the queue but previously it would have still been on the queue, but since the process is stopped, who can tell? In fact if the data was already present then sleep(0 would have never been called, so the blocking would (even now) happen at the user boundary. All I'm doing is making it consitent. > > I'm still not getting a warm fuzzy that allowing the userland context to > complete and then block at the userland boundary is a good idea. I'm > not saying it's a bad idea, but I'm almost positive there are gremlins > hiding in the details here. :) Userland context? where does userland context come into it? I'm talking about when a syscall blocks after or shortly before a SIGSTOP is received. > > > It waits there for the CONT signal. If the CONT happens before > > the data arrives or the timeout expires the flag is simply cleared again. > > In effect, you're avoiding moving the process from the STOPPED queue and > back to the SLEEP queue. I'm allowing it to STAY in the SLEEEP queue, knowing that when it decides to continue, it can not get back to userland. because I've blocked that road with a fallen tree. > > > It doesn't make such a huge difference now but when there are multiple > > threads in a process, being able to report to the controlling shell, > > or the debugger "OK its STOPPED" as soon as I can prove that all > > threads are in the kernel and not in user space makes a big > > difference. > > Right, but currently, stopping a process/thread stops it *everywhere*, > including the kernel. We're changing something that has been done this > way for a very long time, and the POLA may come back and bite us. > No it doesn't stop it everywhere. if you have not set PCATCH or if you do not sleep you will proceed forwards oblivious of the pending signal, until you try return to user land, at which point you will be stopped, just as I am suggesting, except I am sugesting that we should ALWAYS stop it there. > > Also, the bit for "this process is STOPPING" can be set by another > > thread and all threads will see it. Saving me from having to run > > around all threads and do all sorts of stuff with each. > > Except that there are now locking issues since the 'other thread' is now > messing around with parts of the thread that may be in use by the thread > itself. (*ick*) > No, it is in the proc struct. All threads sharing the same proc see the same bit. > > I don't necessarily want to do this in -current on it's own. I have > > code that does this in the KSE diffs. I want to know if I've forgotten > > anything because when I commit the KSE diffs I don;t want to discover > > I've broken everything. > > I'm sure you have, but probably not intentionally. There is almost > certainly software that relies on the existing behavior, and will behave > differently (perhaps not wrong) with the aboved described changes. > > > it ispossible I might be able to > > commit this change separatly before hand so that it's an Isolated change > > however and if I can I might think about doing that. > > Maybe a sysctl to turn it off/on? However, I suspect this would be > *really* hard to keep both ways going. > > Thanks for the more detailed explanation!! > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 1:52:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by hub.freebsd.org (Postfix) with ESMTP id A831D37B400 for ; Fri, 8 Mar 2002 01:52:43 -0800 (PST) Received: from regency.nsu.ru ([193.124.210.26] helo=cytherea.weblab.nsu.ru) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 16jH3F-0007gY-00; Fri, 08 Mar 2002 15:52:37 +0600 Received: (from danfe@localhost) by cytherea.weblab.nsu.ru (8.11.6/8.11.6) id g289tNf89014; Fri, 8 Mar 2002 15:55:23 +0600 (NOVT) (envelope-from danfe) Date: Fri, 8 Mar 2002 15:55:23 +0600 From: Alexey Dokuchaev To: Arun Sharma Cc: arch@freebsd.org Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020308155523.A87842@cytherea.weblab.nsu.ru> References: <3C862030.9080108@softweyr.com> <20020306131141.A69228@blossom.cjclark.org> <20020308080100.GA26403@sharma-home.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020308080100.GA26403@sharma-home.net>; from arun@sharma-home.net on Fri, Mar 08, 2002 at 12:01:01AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 08, 2002 at 12:01:01AM -0800, Arun Sharma wrote: > On Wed, Mar 06, 2002 at 01:11:41PM -0800, Crist J. Clark wrote: > > Since we're on the topic of ls(1) having too few options, what I'd > > really like is a switch to print the creation, modified, and access > > times together. > > FreeBSD stores the file creation time ? ctime stands for change time, > not creation time. Well, I've always thought that mtime is the last time file data was modified, ctime is when most recent file status change occured, and atime is when the file was last accessed. I wonder what man stat(2) says... %) ./danfe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 2: 0:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1C5EF37B433 for ; Fri, 8 Mar 2002 02:00:10 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g28A09H06836; Fri, 8 Mar 2002 02:00:09 -0800 (PST) (envelope-from rizzo) Date: Fri, 8 Mar 2002 02:00:09 -0800 From: Luigi Rizzo To: arch@FreeBSD.ORG Subject: Proposed patch: kern.bootdev* sysctl variables Message-ID: <20020308020009.A6535@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Any objection to the following patch to i386/i386/autoconf.c to let userland apps know [an approximation of] the name of the device the kernel was booted from ? The main use would be for startup scripts, such as /etc/rc, which could this way differentiate their behaviour based on the returned result. (I know it can be perfected by not assuming that any hard disk is /dev/ad, but you get the idea...) cheers luigi Index: autoconf.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/autoconf.c,v retrieving revision 1.146.2.2 diff -u -r1.146.2.2 autoconf.c --- autoconf.c 7 Jun 2001 06:05:58 -0000 1.146.2.2 +++ autoconf.c 8 Mar 2002 09:32:36 -0000 @@ -66,6 +66,7 @@ #include #include #include +#include #include #include @@ -105,6 +106,11 @@ device_t nexus_dev; +SYSCTL_ULONG(_kern, OID_AUTO, bootdev, CTLFLAG_RD, &bootdev, 0, ""); +static char bootdevname[MAXPATHLEN]; +SYSCTL_STRING(_kern, OID_AUTO, bootdevname, CTLFLAG_RD, + bootdevname, 0, "Boot device name"); + /* * Determine i/o configuration for a machine. */ @@ -300,9 +306,13 @@ slice = COMPATIBILITY_SLICE; part = RAW_PART; mindev = unit << FDUNITSHIFT; + sprintf(bootdevname, "/dev/fd%d", unit); } else { part = B_PARTITION(bootdev); mindev = dkmakeminor(unit, slice, part); + sprintf(bootdevname, + (slice < BASE_SLICE ? "/dev/ad%d" : "/dev/ad%ds%d"), + unit, slice - BASE_SLICE + 1); } newrootdev = makebdev(majdev, mindev); On Mon, Feb 25, 2002 at 02:30:13PM -0800, Luigi Rizzo wrote: > [bcc-ed to some recent committers to boot2.c] > Hi, > for some stuff I am doing with picobsd (and i think in general this > is useful) it would be nice to know where the kernel was loaded > from. In /sys/boot/i386/boot2/boot2.c this information is stored > in three 8-bit variables: > > dsk.drive also goes into bootinfo.bi_bios_dev > dsk.slice > dsk.part > > Although the latter two are not made available to the kernel, > there are two empty 8-bit fields in struct bootinfo > > u_int8_t bi_pad[2]; > > which could do the job without breaking binary compatibility. > > Any objection on exporting dsk.slice and dsk.part into the bi_pad > fields, possibly starting from 1 so the kernel can tell an uninitialized > value from a good one ? > > (and together with this, perhaps a sysctl variable which builds a > device name from these three values...) > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 2: 9:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 6139837B405 for ; Fri, 8 Mar 2002 02:09:21 -0800 (PST) Received: from pool0067.cvx21-bradley.dialup.earthlink.net ([209.179.192.67] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16jHJQ-0001mZ-00; Fri, 08 Mar 2002 02:09:20 -0800 Message-ID: <3C888DB6.8DF80EE7@mindspring.com> Date: Fri, 08 Mar 2002 02:08:54 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: arch@FreeBSD.ORG Subject: Re: Proposed patch: kern.bootdev* sysctl variables References: <20020308020009.A6535@iguana.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > Any objection to the following patch to i386/i386/autoconf.c > to let userland apps know [an approximation of] the name > of the device the kernel was booted from ? > > The main use would be for startup scripts, such as > /etc/rc, which could this way differentiate their > behaviour based on the returned result. > > (I know it can be perfected by not assuming that > any hard disk is /dev/ad, but you get the idea...) If you grabbed the actual boot information from the tunables in the loader environment (using TUNABLE macros), you could get the actual thing. To see what's available, do a "set" at the loader prompt. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 2:10:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 7376937B416 for ; Fri, 8 Mar 2002 02:10:57 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g28AAbnK015270; Fri, 8 Mar 2002 11:10:37 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: Luigi Rizzo , arch@FreeBSD.ORG Subject: Re: Proposed patch: kern.bootdev* sysctl variables In-Reply-To: Your message of "Fri, 08 Mar 2002 02:08:54 PST." <3C888DB6.8DF80EE7@mindspring.com> Date: Fri, 08 Mar 2002 11:10:37 +0100 Message-ID: <15269.1015582237@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3C888DB6.8DF80EE7@mindspring.com>, Terry Lambert writes: >Luigi Rizzo wrote: >> Any objection to the following patch to i386/i386/autoconf.c >> to let userland apps know [an approximation of] the name >> of the device the kernel was booted from ? >> >> The main use would be for startup scripts, such as >> /etc/rc, which could this way differentiate their >> behaviour based on the returned result. >> >> (I know it can be perfected by not assuming that >> any hard disk is /dev/ad, but you get the idea...) > >If you grabbed the actual boot information from the >tunables in the loader environment (using TUNABLE >macros), you could get the actual thing. But that might not be the real thing. The kernel will ask for a root if it's initial instruction is wrong, so you cannot return the hint from the bootloader unless you know for sure that you actually ended up using that. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 2:12:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 7163C37B404 for ; Fri, 8 Mar 2002 02:12:40 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g28ACdC07114; Fri, 8 Mar 2002 02:12:39 -0800 (PST) (envelope-from rizzo) Date: Fri, 8 Mar 2002 02:12:39 -0800 From: Luigi Rizzo To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: Proposed patch: kern.bootdev* sysctl variables Message-ID: <20020308021239.C6535@iguana.icir.org> References: <20020308020009.A6535@iguana.icir.org> <3C888DB6.8DF80EE7@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C888DB6.8DF80EE7@mindspring.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The main use of this would be picobsd, which does not use the loader: Default: 0:ad(0,a)/kernel boot: WARNING: loader(8) metadata is missing! Copyright (c) 1992-2002 The FreeBSD Project. ... cheers luigi On Fri, Mar 08, 2002 at 02:08:54AM -0800, Terry Lambert wrote: > > > > (I know it can be perfected by not assuming that > > any hard disk is /dev/ad, but you get the idea...) > > If you grabbed the actual boot information from the > tunables in the loader environment (using TUNABLE > macros), you could get the actual thing. > > To see what's available, do a "set" at the loader prompt. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 6:25: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 5973F37B416; Fri, 8 Mar 2002 06:25:00 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id g28EOu550423; Fri, 8 Mar 2002 14:24:56 GMT (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.2/8.12.2) with ESMTP id g28EMIH6060352; Fri, 8 Mar 2002 14:22:18 GMT (envelope-from brian@freebsd-services.com) Message-Id: <200203081422.g28EMIH6060352@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Luigi Rizzo Cc: Brooks Davis , "Crist J. Clark" , Archie Cobbs , Julian Elischer , freebsd-arch@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Patches to if_loop + the interface cloning framework In-Reply-To: Message from Luigi Rizzo of "Mon, 04 Mar 2002 10:32:42 PST." <20020304103242.A67658@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 14:22:18 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Mon, Mar 04, 2002 at 10:23:35AM -0800, Brooks Davis wrote: > > From a _practical_ standpoint, a loopback interface must be compiled > > in at this time. However, that's not what Archie and I are arguing. > > I'm arguing that since the requirement is not there in theory, we should > > not be making moves which require it in practice. The direction I'd like > > speaking of which , would it be reasonable to merge if_disc and if_loop ? > The former is basically a stripped down version of the latter, so > it hardly justifies a separate device It'd also be reasonable to have if_disc create ``discN'' devices... ``dsN'' doesn't seem... orthogonal :*I > cheers > luigi -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 6:31: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 9F70337B405 for ; Fri, 8 Mar 2002 06:31:03 -0800 (PST) Received: (qmail 46193 invoked from network); 8 Mar 2002 14:29:14 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 8 Mar 2002 14:29:14 -0000 Message-ID: <3C88CAE6.6B5D026A@pipeline.ch> Date: Fri, 08 Mar 2002 15:29:58 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Somers Cc: Luigi Rizzo , Brooks Davis , "Crist J. Clark" , Archie Cobbs , Julian Elischer , freebsd-arch@FreeBSD.ORG Subject: Re: Patches to if_loop + the interface cloning framework References: <200203081422.g28EMIH6060352@hak.lan.Awfulhak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Brian Somers wrote: > > > On Mon, Mar 04, 2002 at 10:23:35AM -0800, Brooks Davis wrote: > > > From a _practical_ standpoint, a loopback interface must be compiled > > > in at this time. However, that's not what Archie and I are arguing. > > > I'm arguing that since the requirement is not there in theory, we should > > > not be making moves which require it in practice. The direction I'd like > > > > speaking of which , would it be reasonable to merge if_disc and if_loop ? > > The former is basically a stripped down version of the latter, so > > it hardly justifies a separate device > > It'd also be reasonable to have if_disc create ``discN'' devices... > ``dsN'' doesn't seem... orthogonal :*I I would prefer to call it if_null or null0. This is what the routers call it. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 8:18:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 8DAB737B405 for ; Fri, 8 Mar 2002 08:18:11 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA11663; Fri, 8 Mar 2002 09:18:06 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g28GI6r10503; Fri, 8 Mar 2002 09:18:06 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15496.58430.16748.970354@caddis.yogotech.com> Date: Fri, 8 Mar 2002 09:18:06 -0700 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: References: <15496.23508.148366.980354@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > In effect, the context is actually still active inside the kernel, even > > though the userland process is never given notice. I could see this > > having *really* strange effects for things that do network I/O. > > Often-times I've suspended processes inside of gdb so I could set > > breakpoints knowing full well that *NOTHING* was going to happen, even > > if I was in the middle of a system call. > > You'd be surprised then because once the send() is done, the network IO > will happen independently of the process. I'm more thinking of send. Once the send() system call has queued the data for sending, it's been 'sent' (ie; the stack has it, and will 'DTRT' with it). > this is no different. Except for read() or recvfrom() system calls, and potentially things like 'sendfile()'. Also, write() may behave differently (since write involve disk writing, not network writing). > from the time you do the ^Z to the time the syscall thinks of returning is > how long? If you say 3 seconds then all that is different is that in my > case the data has been taken off the queue but previously it would have > still been on the queue, but since the process is stopped, > who can tell? A lot can happen in 3 seconds. :) > In fact if the data was already present then sleep(0 would > have never been called, so the blocking would (even now) happen > at the user boundary. All I'm doing is making it consitent. Agreed. > > I'm still not getting a warm fuzzy that allowing the userland context to > > complete and then block at the userland boundary is a good idea. I'm > > not saying it's a bad idea, but I'm almost positive there are gremlins > > hiding in the details here. :) > > Userland context? where does userland context come into it? Sorry, I meant 'kernel context' above. My bad. I'll repeat. I'm still not getting a warm fuzzy that allowing the kernel context to complete and then block at the userland boundary is a good idea. I'm not saying it's a bad idea, but I'm almost positive there are gremlins hiding in the details here. :) > > > It waits there for the CONT signal. If the CONT happens before > > > the data arrives or the timeout expires the flag is simply cleared again. > > > > In effect, you're avoiding moving the process from the STOPPED queue and > > back to the SLEEP queue. > > I'm allowing it to STAY in the SLEEEP queue, knowing that when it decides > to continue, it can not get back to userland. because I've blocked that > road with a fallen tree. I know, but prior to this change, it moved to the STOPPED queue, and then back to the SLEEP queue upon receipt of SIGSTOP and SIGCONT signals. > > > It doesn't make such a huge difference now but when there are multiple > > > threads in a process, being able to report to the controlling shell, > > > or the debugger "OK its STOPPED" as soon as I can prove that all > > > threads are in the kernel and not in user space makes a big > > > difference. > > > > Right, but currently, stopping a process/thread stops it *everywhere*, > > including the kernel. We're changing something that has been done this > > way for a very long time, and the POLA may come back and bite us. > > No it doesn't stop it everywhere. if you have not set PCATCH or if you > do not sleep you will proceed forwards oblivious of the pending signal, > until you try return to user land, at which point you will be stopped, > just as I am suggesting, except I am sugesting that we should ALWAYS > stop it there. I'm assuming we're talking about processes with PCATCH set, since that's the behavior that will change. Bu, thanks for clarifying. > > > Also, the bit for "this process is STOPPING" can be set by another > > > thread and all threads will see it. Saving me from having to run > > > around all threads and do all sorts of stuff with each. > > > > Except that there are now locking issues since the 'other thread' is now > > messing around with parts of the thread that may be in use by the thread > > itself. (*ick*) > > No, it is in the proc struct. > All threads sharing the same proc see the same bit. Then we have the potential for race issues, since it could be possible for one thread to get a SIGSTOP, and another to get a SIGCONT very soon after, so we must guarantee that the order these are received is done correctly. Doing this 'safely' almost always involves locking. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 9:59:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 1D75B37B41A for ; Fri, 8 Mar 2002 09:59:43 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g28HxfNH154108; Fri, 8 Mar 2002 12:59:41 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020308020009.A6535@iguana.icir.org> References: <20020308020009.A6535@iguana.icir.org> Date: Fri, 8 Mar 2002 12:59:40 -0500 To: Luigi Rizzo , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Proposed patch: kern.bootdev* sysctl variables Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:00 AM -0800 3/8/02, Luigi Rizzo wrote: >Any objection to the following patch to i386/i386/autoconf.c >to let userland apps know [an approximation of] the name >of the device the kernel was booted from ? > >The main use would be for startup scripts, such as /etc/rc, >which could this way differentiate their behaviour based >on the returned result. I definitely like the goal. >(I know it can be perfected by not assuming that >any hard disk is /dev/ad, but you get the idea...) My machines tend to have scsi drives (and some of them have only scsi hard drives), and I can also boot off of CD's. If something like this is added, I think it pretty much has to give the correct answer in all cases. If not, it should give a helpful clue, but not guess at the answer and then present that guess as fact.. Ie, instead of "/dev/ad%ds%d", maybe return "disk%ds%d"... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 10: 3:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id E240637B42B; Fri, 8 Mar 2002 10:03:51 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g28I3kNH056844; Fri, 8 Mar 2002 13:03:46 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020306131141.A69228@blossom.cjclark.org> References: <3C862030.9080108@softweyr.com> <20020306131141.A69228@blossom.cjclark.org> Date: Fri, 8 Mar 2002 13:03:45 -0500 To: "Crist J. Clark" , Wes Peters From: Garance A Drosihn Subject: Re: Sorting and Matching options for ls(1) Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 1:11 PM -0800 3/6/02, Crist J. Clark wrote: >Since we're on the topic of ls(1) having too few options, what I'd >really like is a switch to print the creation, modified, and access >times together. Basically, dumping the whole stat(2) structure would >be nice (some other UNIXes have a separate command to do this). I like the suggestion for -M and -S for 'ls'. I also like the idea of something that could dump the entire stat structure, but that strikes me as being better as a separate utility. What do the other unixes call their command which does this? -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 10:24:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 68CB137B404 for ; Fri, 8 Mar 2002 10:24:54 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA01153; Sat, 9 Mar 2002 05:24:44 +1100 Date: Sat, 9 Mar 2002 05:25:28 +1100 (EST) From: Bruce Evans X-X-Sender: To: Garance A Drosihn Cc: Luigi Rizzo , Subject: Re: Proposed patch: kern.bootdev* sysctl variables In-Reply-To: Message-ID: <20020309051737.V4183-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Mar 2002, Garance A Drosihn wrote: > At 2:00 AM -0800 3/8/02, Luigi Rizzo wrote: > >Any objection to the following patch to i386/i386/autoconf.c > >to let userland apps know [an approximation of] the name > >of the device the kernel was booted from ? > > > >The main use would be for startup scripts, such as /etc/rc, > >which could this way differentiate their behaviour based > >on the returned result. > > I definitely like the goal. > > >(I know it can be perfected by not assuming that > >any hard disk is /dev/ad, but you get the idea...) > > My machines tend to have scsi drives (and some of them have only > scsi hard drives), and I can also boot off of CD's. If something > like this is added, I think it pretty much has to give the correct > answer in all cases. If not, it should give a helpful clue, but > not guess at the answer and then present that guess as fact.. > > Ie, instead of "/dev/ad%ds%d", maybe return "disk%ds%d"... I think this doesn't belong in i386/autoconf.c. Old versions of i386/autoconfig.c determined the driver name correctly, but the code for this has mostly migrated to mostly-MI code in kern/vfs_conf.c and kern/subr_disk.c. The MI code can determine the boot device just as easily as it can determine to root device, given suitable input. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 10:27: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id F3C1E37B416 for ; Fri, 8 Mar 2002 10:26:58 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g28IQuR12152; Fri, 8 Mar 2002 10:26:56 -0800 (PST) (envelope-from rizzo) Date: Fri, 8 Mar 2002 10:26:56 -0800 From: Luigi Rizzo To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Proposed patch: kern.bootdev* sysctl variables Message-ID: <20020308102656.A9076@iguana.icir.org> References: <20020308020009.A6535@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >(I know it can be perfected by not assuming that > >any hard disk is /dev/ad, but you get the idea...) > ... > scsi hard drives), and I can also boot off of CD's. If something > like this is added, I think it pretty much has to give the correct > answer in all cases. If not, it should give a helpful clue, but you can get the correct major/minor numbers for the device from kern/bootdev: # sysctl kern.bootdev kern.bootdev: 2687500318 but the mapping to names of course is totally user-dependent. One option could be to use the major/minor numbers to create an entry, /dev/bootdev, to be used later for the mount. Or to add a mount option so you can pass it major/minor numbers as opposed to device names (so you do not need a writable filesystem to create the entry). cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 10:52:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id E5D4837B400 for ; Fri, 8 Mar 2002 10:52:09 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g28IpnnK048208; Fri, 8 Mar 2002 19:51:50 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Luigi Rizzo Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Proposed patch: kern.bootdev* sysctl variables In-Reply-To: Your message of "Fri, 08 Mar 2002 10:26:56 PST." <20020308102656.A9076@iguana.icir.org> Date: Fri, 08 Mar 2002 19:51:49 +0100 Message-ID: <48207.1015613509@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020308102656.A9076@iguana.icir.org>, Luigi Rizzo writes: >> >(I know it can be perfected by not assuming that >> >any hard disk is /dev/ad, but you get the idea...) >> >... >> scsi hard drives), and I can also boot off of CD's. If something >> like this is added, I think it pretty much has to give the correct >> answer in all cases. If not, it should give a helpful clue, but > >you can get the correct major/minor numbers for the device >from kern/bootdev: > > # sysctl kern.bootdev > kern.bootdev: 2687500318 > >but the mapping to names of course is totally user-dependent. Uhm devname(3) ? -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 10:52:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id A7C5637B400 for ; Fri, 8 Mar 2002 10:52:33 -0800 (PST) Received: from pool0314.cvx40-bradley.dialup.earthlink.net ([216.244.43.59] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16jPTd-0007lw-00; Fri, 08 Mar 2002 10:52:26 -0800 Message-ID: <3C890859.4FB4F9D@mindspring.com> Date: Fri, 08 Mar 2002 10:52:09 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) References: <15496.23508.148366.980354@caddis.yogotech.com> <15496.58430.16748.970354@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > You'd be surprised then because once the send() is done, the network IO > > will happen independently of the process. > > I'm more thinking of send. Once the send() system call has queued the > data for sending, it's been 'sent' (ie; the stack has it, and will > 'DTRT' with it). The amount it queues onto the sockbuf is limited to the available space. Thus a send of a very large amount of data means that only part of it gets queued for sending. This is not a restartable situation, unless restart can pick up where it left off, since the sending of a partial load of data can modify peer state, as well, and that state is not under the control of the user process on your end. So just returning an EINTR for a send (or sendfile, etc.) means that the peer state is unknown. At that point, you must abandon the connection. While HTTP is tolerant to connection abandonment (and, if both the client and the server support ranges, can even recover automatically), things like FTP servers are not (an abandoned connection will not result in an automatic "reget" or "reput" for most every FTP). > > this is no different. > > Except for read() or recvfrom() system calls, and potentially things > like 'sendfile()'. Also, write() may behave differently (since write > involve disk writing, not network writing). Yes. Sendfile is very sensitive, since it is a loop to fill the socket buffer up to its limit (as well as the send window), and interrupting this loop without saving the current state damages it. Actually, this sort of begs that the sendfile interface be modified to take a context structure, wich is updated, so that it can be resumed when interupted. The context at the time of interupt would need to reflect the reality of the data that has been sent. For the read/recvfrom, this also kind of begs for a "recvfile", since there's no way you can modify them without futzing with the POSIX-ly correctness of the interface. > > from the time you do the ^Z to the time the syscall thinks of returning is > > how long? If you say 3 seconds then all that is different is that in my > > case the data has been taken off the queue but previously it would have > > still been on the queue, but since the process is stopped, > > who can tell? > > A lot can happen in 3 seconds. :) Or not happen. The dichotomy between a gigabit link on a server and a 28k link on a dialup client, damages a lot of the end-to-end assumptions that interrupting with EINTR tries to make, since it ignores the idea of a pool retention that is out of the control of the sender, once the send is initiated. For local disk, the problem is less (or at least, can be made less, if you want to hack up uiomove and the write path), because you can guarantee the relative atomicity of the operations. If they are initiated in block size increments on block boundaries, you can actually make a 100% guarantee (some code mods to the current code are required, but they are pretty trivial). You won't avoid the page-in-before-write-out in all cases, but you can avoid the case of partial-write-complete-and-interrupted-leaving-interminate-state case. > > In fact if the data was already present then sleep(0 would > > have never been called, so the blocking would (even now) happen > > at the user boundary. All I'm doing is making it consitent. > > Agreed. Actually, this isn't true. The wait for the window drain on a socket write *does* result in a sleep. Also the wait for a subsequent page-in for a write spanning two pages without a cluster adjacency on disk. > Sorry, I meant 'kernel context' above. My bad. I'll repeat. > > I'm still not getting a warm fuzzy that allowing the kernel context to > complete and then block at the userland boundary is a good idea. I'm > not saying it's a bad idea, but I'm almost positive there are gremlins > hiding in the details here. :) What are very large gremlins called... "goblins"? If they're there, then they're big. Of course, the only way to find out is to stop hypothesizing, and go look... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 11:39: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id EE2DA37B41B for ; Fri, 8 Mar 2002 11:38:32 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308193832.KBSA1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Fri, 8 Mar 2002 19:38:32 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g28JcOu12857; Fri, 8 Mar 2002 11:38:24 -0800 (PST) (envelope-from cjc) Date: Fri, 8 Mar 2002 11:38:23 -0800 From: "Crist J. Clark" To: Garance A Drosihn Cc: Wes Peters , arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020308113823.B57999@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <3C862030.9080108@softweyr.com> <20020306131141.A69228@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Fri, Mar 08, 2002 at 01:03:45PM -0500 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 08, 2002 at 01:03:45PM -0500, Garance A Drosihn wrote: > At 1:11 PM -0800 3/6/02, Crist J. Clark wrote: > >Since we're on the topic of ls(1) having too few options, what I'd > >really like is a switch to print the creation, modified, and access > >times together. Basically, dumping the whole stat(2) structure would > >be nice (some other UNIXes have a separate command to do this). > > I like the suggestion for -M and -S for 'ls'. I also like the > idea of something that could dump the entire stat structure, but > that strikes me as being better as a separate utility. What do > the other unixes call their command which does this? IIRC, the first time I ran into such a thing was IRIX, and I found it very useful. Here is their stat(1M) manpage, http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/cat1/stat.z -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 12: 7:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tomts17-srv.bellnexxia.net (tomts17.bellnexxia.net [209.226.175.71]) by hub.freebsd.org (Postfix) with ESMTP id 4A89E37B404 for ; Fri, 8 Mar 2002 12:07:39 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.191.9]) by tomts17-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20020308200738.TLRH4161.tomts17-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Fri, 8 Mar 2002 15:07:38 -0500 Received: from lenny.anarcat.dyndns.org (lenny.anarcat.dyndns.org [192.168.0.4]) by khan.anarcat.dyndns.org (Postfix) with SMTP id 7DF5D190E; Fri, 8 Mar 2002 15:07:31 -0500 (EST) Received: by lenny.anarcat.dyndns.org (sSMTP sendmail emulation); Fri, 8 Mar 2002 15:06:52 -0500 Date: Fri, 8 Mar 2002 15:06:52 -0500 From: The Anarcat To: cjclark@alum.mit.edu Cc: Garance A Drosihn , Wes Peters , arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020308200652.GB547@lenny.anarcat.dyndns.org> References: <3C862030.9080108@softweyr.com> <20020306131141.A69228@blossom.cjclark.org> <20020308113823.B57999@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: <20020308113823.B57999@blossom.cjclark.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri Mar 08, 2002 at 11:38:23AM -0800, Crist J. Clark wrote: > On Fri, Mar 08, 2002 at 01:03:45PM -0500, Garance A Drosihn wrote: > > At 1:11 PM -0800 3/6/02, Crist J. Clark wrote: > > >Since we're on the topic of ls(1) having too few options, what I'd > > >really like is a switch to print the creation, modified, and access > > >times together. Basically, dumping the whole stat(2) structure would > > >be nice (some other UNIXes have a separate command to do this). > >=20 > > I like the suggestion for -M and -S for 'ls'. I also like the > > idea of something that could dump the entire stat structure, but > > that strikes me as being better as a separate utility. What do > > the other unixes call their command which does this? >=20 > IIRC, the first time I ran into such a thing was IRIX, and I found it > very useful. Here is their stat(1M) manpage, >=20 > http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=3D0650&db= =3Dman&fname=3D/usr/share/catman/a_man/cat1/stat.z And there's of course sysutils/stat. I would be for including this in the base system. It is extremely useful. A. --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyJGdwACgkQttcWHAnWiGfRowCfXAis//C/ZbC34rLKLGxWy+FP M24AnjhBRHLrXv2rzFxnVV+wTdzdCiRj =mWHn -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 12:20:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 0AA6637B405 for ; Fri, 8 Mar 2002 12:20:11 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308202010.DDVW1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 20:20:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA49764; Fri, 8 Mar 2002 12:01:09 -0800 (PST) Date: Fri, 8 Mar 2002 12:01:08 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <15496.58430.16748.970354@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Mar 2002, Nate Williams wrote: > > Except for read() or recvfrom() system calls, and potentially things > like 'sendfile()'. Also, write() may behave differently (since write > involve disk writing, not network writing). I don't actually see how read()/recv() acts differently. > > Userland context? where does userland context come into it? > > Sorry, I meant 'kernel context' above. My bad. I'll repeat. > > I'm still not getting a warm fuzzy that allowing the kernel context to > complete and then block at the userland boundary is a good idea. I'm > not saying it's a bad idea, but I'm almost positive there are gremlins > hiding in the details here. :) Me too but I can't find the little devil. That's why I'm asking everyone here.. > > I know, but prior to this change, it moved to the STOPPED queue, and > then back to the SLEEP queue upon receipt of SIGSTOP and SIGCONT > signals. there is no STOPPED queue. STOPPED processes are on no queue. they assume that teh parent knows they are there and will restart them. (hmmmm) > > No it doesn't stop it everywhere. if you have not set PCATCH or if you > > do not sleep you will proceed forwards oblivious of the pending signal, > > until you try return to user land, at which point you will be stopped, > > just as I am suggesting, except I am sugesting that we should ALWAYS > > stop it there. > > I'm assuming we're talking about processes with PCATCH set, since that's > the behavior that will change. But, thanks for clarifying. > Then we have the potential for race issues, since it could be possible > for one thread to get a SIGSTOP, and another to get a SIGCONT very soon > after, so we must guarantee that the order these are received is done > correctly. Doing this 'safely' almost always involves locking. there is a PROC_LOCK(p) in that part of the code anyhow.. so we might as well do it there (at the user boundary). > > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 12:21:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 1497637B405 for ; Fri, 8 Mar 2002 12:21:27 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g28KLGQ23266; Fri, 8 Mar 2002 12:21:16 -0800 (PST) (envelope-from obrien) Date: Fri, 8 Mar 2002 12:17:13 -0800 From: "David O'Brien" To: Luigi Rizzo Cc: arch@FreeBSD.ORG Subject: Re: Proposed patch: kern.bootdev* sysctl variables Message-ID: <20020308121713.D22956@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020308020009.A6535@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020308020009.A6535@iguana.icir.org>; from rizzo@icir.org on Fri, Mar 08, 2002 at 02:00:09AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 08, 2002 at 02:00:09AM -0800, Luigi Rizzo wrote: > Any objection to the following patch to i386/i386/autoconf.c > to let userland apps know [an approximation of] the name > of the device the kernel was booted from ? Yes. Things like this should not be committed to only i386. We should have the same sysctl's on all platforms unless they are truly platform Dependant. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 12:24:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 110D237B41C for ; Fri, 8 Mar 2002 12:23:56 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308202356.DGVW1214.rwcrmhc54.attbi.com@blossom.cjclark.org>; Fri, 8 Mar 2002 20:23:56 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g28KNtX13515; Fri, 8 Mar 2002 12:23:55 -0800 (PST) (envelope-from cjc) Date: Fri, 8 Mar 2002 12:23:55 -0800 From: "Crist J. Clark" To: The Anarcat Cc: Garance A Drosihn , Wes Peters , arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020308122355.D57999@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <3C862030.9080108@softweyr.com> <20020306131141.A69228@blossom.cjclark.org> <20020308113823.B57999@blossom.cjclark.org> <20020308200652.GB547@lenny.anarcat.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020308200652.GB547@lenny.anarcat.dyndns.org>; from anarcat@anarcat.dyndns.org on Fri, Mar 08, 2002 at 03:06:52PM -0500 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 08, 2002 at 03:06:52PM -0500, The Anarcat wrote: > On Fri Mar 08, 2002 at 11:38:23AM -0800, Crist J. Clark wrote: > > On Fri, Mar 08, 2002 at 01:03:45PM -0500, Garance A Drosihn wrote: > > > At 1:11 PM -0800 3/6/02, Crist J. Clark wrote: > > > >Since we're on the topic of ls(1) having too few options, what I'd > > > >really like is a switch to print the creation, modified, and access > > > >times together. Basically, dumping the whole stat(2) structure would > > > >be nice (some other UNIXes have a separate command to do this). > > > > > > I like the suggestion for -M and -S for 'ls'. I also like the > > > idea of something that could dump the entire stat structure, but > > > that strikes me as being better as a separate utility. What do > > > the other unixes call their command which does this? > > > > IIRC, the first time I ran into such a thing was IRIX, and I found it > > very useful. Here is their stat(1M) manpage, > > > > http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/cat1/stat.z > > And there's of course sysutils/stat. > > I would be for including this in the base system. It is extremely > useful. That's pretty much it. Some features of it I like and some I don't. But the problem with that code is that it is in somewhat of a licensing/copyright limbo. It looks like it was grabbed off of Usenet. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 12:40:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 2637E37B420 for ; Fri, 8 Mar 2002 12:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308204009.KOOU2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 20:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA49904; Fri, 8 Mar 2002 12:38:39 -0800 (PST) Date: Fri, 8 Mar 2002 12:38:38 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <3C890859.4FB4F9D@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Mar 2002, Terry Lambert wrote: > Nate Williams wrote: > > > You'd be surprised then because once the send() is done, the network IO > > > will happen independently of the process. > > > > I'm more thinking of send. Once the send() system call has queued the > > data for sending, it's been 'sent' (ie; the stack has it, and will > > 'DTRT' with it). > > The amount it queues onto the sockbuf is limited to the > available space. Thus a send of a very large amount of > data means that only part of it gets queued for sending. > > This is not a restartable situation, unless restart can > pick up where it left off, since the sending of a partial > load of data can modify peer state, as well, and that > state is not under the control of the user process on > your end. > > So just returning an EINTR for a send (or sendfile, etc.) > means that the peer state is unknown. STOP doesn not force an abandonment of the syscall that is SLEEPING (even I was confused about this at one stage) so RESTART stuff is not needed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 12:40:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 560B437B400 for ; Fri, 8 Mar 2002 12:40:21 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308204020.KOSU2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 20:40:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA49898; Fri, 8 Mar 2002 12:36:46 -0800 (PST) Date: Fri, 8 Mar 2002 12:36:44 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <3C890859.4FB4F9D@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Mar 2002, Terry Lambert wrote: > Nate Williams wrote: > > > You'd be surprised then because once the send() is done, the network IO > > > will happen independently of the process. > > > > I'm more thinking of send. Once the send() system call has queued the > > data for sending, it's been 'sent' (ie; the stack has it, and will > > 'DTRT' with it). Ok here is a summary of behavioural changes I think we'd see. *** From the program point of view: Pretty much no change. *** From a debugger's point of view: Pretty much no change.. SIGCHLD arrives when you may examine the process's mamory without bumping into a running thread changing things. *** From a completely unrelated process's point of view: if you are receiving data from the process in question, there may be the following changes: 1/ if you ^Z the sender, when it is doing a write that is large enough to overflow the send buffer, so that it needs to do it in several bites, then at the moment, the data flow may be paused between these bites, say after 16k out of 33KB written. In the new case the entire 33K would be written, after which the thread would block. If you can type ^Z that fast that this makes a difference to you on a 10Mb ethernet, I'd be amazed. Someone looking on a slow link might notice, but I'd be surprised if it mattered to anyone considering that the default buffer size would probably effect this same stop point as well. 2/ similar with sendfile. The entire file would continue to be sent, however the process wouldn't be able to tell the difference. it would be stopped. I think that sendfile could be special case'd if we desperatly needed that behaviour (the ability to ^Z the server would stop the stream) but I doubt anyone would really care. 3/ If you are talking TO a process that is ^Z'd, it might read a bit more data from the receive buffers before blocking, which might mean that the sender can send that much data extra before blocking. I doubt that this would be noticed by anyone in this galaxy. A definition of STOP that includes "will stop immediatly if in user space, or AFTER the current system call completes if in the kernel" would pretty much describe it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 12:44:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id 55A5C37B405 for ; Fri, 8 Mar 2002 12:44:00 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.191.9]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20020308204354.UKAY1656.tomts13-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Fri, 8 Mar 2002 15:43:54 -0500 Received: from lenny.anarcat.dyndns.org (lenny.anarcat.dyndns.org [192.168.0.4]) by khan.anarcat.dyndns.org (Postfix) with SMTP id D610E190E; Fri, 8 Mar 2002 15:43:51 -0500 (EST) Received: by lenny.anarcat.dyndns.org (sSMTP sendmail emulation); Fri, 8 Mar 2002 15:43:13 -0500 Date: Fri, 8 Mar 2002 15:43:13 -0500 From: The Anarcat To: cjclark@alum.mit.edu Cc: Garance A Drosihn , Wes Peters , arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) Message-ID: <20020308204313.GD547@lenny.anarcat.dyndns.org> References: <3C862030.9080108@softweyr.com> <20020306131141.A69228@blossom.cjclark.org> <20020308113823.B57999@blossom.cjclark.org> <20020308200652.GB547@lenny.anarcat.dyndns.org> <20020308122355.D57999@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NklN7DEeGtkPCoo3" Content-Disposition: inline In-Reply-To: <20020308122355.D57999@blossom.cjclark.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --NklN7DEeGtkPCoo3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri Mar 08, 2002 at 12:23:55PM -0800, Crist J. Clark wrote: > On Fri, Mar 08, 2002 at 03:06:52PM -0500, The Anarcat wrote: > >=20 > > And there's of course sysutils/stat. > >=20 > > I would be for including this in the base system. It is extremely > > useful. >=20 > That's pretty much it. Some features of it I like and some I > don't. But the problem with that code is that it is in somewhat of a > licensing/copyright limbo. It looks like it was grabbed off of > Usenet. Bah. It's such a trivial program one could be re-written from scratch. Heck, even I could do it. ;) A> --NklN7DEeGtkPCoo3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyJImAACgkQttcWHAnWiGduZwCeP8WRiwaBSJaV5XZBQLGOLSOV 9DAAniEjqyaTutNBlZHYaUPsActheKeg =ri2z -----END PGP SIGNATURE----- --NklN7DEeGtkPCoo3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 13:12:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8B03D37B400; Fri, 8 Mar 2002 13:12:47 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g28LClJ13454; Fri, 8 Mar 2002 13:12:47 -0800 (PST) (envelope-from rizzo) Date: Fri, 8 Mar 2002 13:12:47 -0800 From: Luigi Rizzo To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: Proposed patch: kern.bootdev* sysctl variables Message-ID: <20020308131247.A13071@iguana.icir.org> References: <20020308020009.A6535@iguana.icir.org> <20020308121713.D22956@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020308121713.D22956@dragon.nuxi.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I agree that we should have the same sysctl on all platforms. The issues are 1. what information should we export so that either the shell or some trivial userland program can make use of it ? For this one, a possibility could be to export the major/minor numbers for the device, and then maybe follow phk's suggestion of using devname(3) (however: does it work with devfs ?) or some equivalent approach. 2. where to grab the information we need. On this one, it looks like the bootdev info (and rootdev as well) is generated/available in MD files, and perhaps even in different forms on different architectures. See i386/i386/autoconf.c and alpha/alpha/autoconf.c for rootdevnames, for instance. So, for sure we can put the SYSCTL_* decls in some MI file, but I believe we will definitely need minor patches to the above-mentioned MD files to normalize the information. Does this make sense, and if not, can you be more specific on how to implement this feature in a way you would not object to ? cheers luigi On Fri, Mar 08, 2002 at 12:17:13PM -0800, David O'Brien wrote: > On Fri, Mar 08, 2002 at 02:00:09AM -0800, Luigi Rizzo wrote: > > Any objection to the following patch to i386/i386/autoconf.c > > to let userland apps know [an approximation of] the name > > of the device the kernel was booted from ? > > Yes. Things like this should not be committed to only i386. > We should have the same sysctl's on all platforms unless they are truly > platform Dependant. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 15:51: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D660037B400; Fri, 8 Mar 2002 15:51:04 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g28Np3Z46611; Fri, 8 Mar 2002 18:51:03 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200203082351.g28Np3Z46611@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: The Anarcat Cc: cjclark@alum.mit.edu, Garance A Drosihn , Wes Peters , arch@FreeBSD.ORG Subject: Re: Sorting and Matching options for ls(1) In-Reply-To: Message from The Anarcat of "Fri, 08 Mar 2002 15:43:13 EST." <20020308204313.GD547@lenny.anarcat.dyndns.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 18:51:03 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The Anarcat wrote: > On Fri Mar 08, 2002 at 12:23:55PM -0800, Crist J. Clark wrote: > > On Fri, Mar 08, 2002 at 03:06:52PM -0500, The Anarcat wrote: > > > > > > And there's of course sysutils/stat. > > > > > > I would be for including this in the base system. It is extremely > > > useful. > > > > That's pretty much it. Some features of it I like and some I > > don't. But the problem with that code is that it is in somewhat of a > > licensing/copyright limbo. It looks like it was grabbed off of > > Usenet. > > Bah. It's such a trivial program one could be re-written from scratch. > Heck, even I could do it. ;) How about you reimplement, say, IRIX's from the manpage? That would be neat :) -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 8 21: 8:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E8B9037B404 for ; Fri, 8 Mar 2002 21:08:35 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA09438; Sat, 9 Mar 2002 16:08:12 +1100 Date: Sat, 9 Mar 2002 16:08:57 +1100 (EST) From: Bruce Evans X-X-Sender: To: Poul-Henning Kamp Cc: Luigi Rizzo , Garance A Drosihn , Subject: Re: Proposed patch: kern.bootdev* sysctl variables In-Reply-To: <48207.1015613509@critter.freebsd.dk> Message-ID: <20020309155205.T4263-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Mar 2002, Poul-Henning Kamp wrote: > In message <20020308102656.A9076@iguana.icir.org>, Luigi Rizzo writes: > >you can get the correct major/minor numbers for the device > >from kern/bootdev: > > > > # sysctl kern.bootdev > > kern.bootdev: 2687500318 > > > >but the mapping to names of course is totally user-dependent. > > Uhm devname(3) ? No. kern.bootdev (if it actually a copy of the boot variable) is not a udev_t: u_long bootdev = 0; /* not a dev_t - encoding is different */ E.g., 2687500318 is 0xA030001E; see and old versions of i386/autoconf.c for how to decode this correctly. I still use my version of the old versions because I don't use /boot/loader and boot device handling has regressed since FreeBSD-2 if /boot/loader is not used. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 4:27:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2B5A337B416 for ; Sat, 9 Mar 2002 04:27:29 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g29CRS321269; Sat, 9 Mar 2002 04:27:28 -0800 (PST) (envelope-from rizzo) Date: Sat, 9 Mar 2002 04:27:28 -0800 From: Luigi Rizzo To: arch@freebsd.org Subject: For review: machdep.bootdev sysctl (for i386) Message-ID: <20020309042728.A21016@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Looking at a way to determine the boot device from userland, I have come to the conclusion that the most reasonable way is to export to userland whatever information the kernel has (and this is machine dependent, sorry!), and let some userland program (getbootdev(1)) convert it into a reasonable device name. In the i386 case, the relevant information is in the "bootdev" variable, defined in i386/i386/autoconf.c and initialized in i386/i386/locore.s In the Alpha case, there is no "bootdev" variable, so I need feedback from Alpha experts on this. Unless someone can suggest a better way (i.e. more general and as little intrusive -- we are talking about a 3-line change here!) I would like to commit this simple patch, moving bootdev (which is currently written in locore.s and unused otherwise) to machdep.c where the SYSCTL hook exports it. As for the userland program to parse machdep.bootdev, for the time being i am going to write it as part of the picobsd "tinyware", pending suggestions on the best place to put it. There are several options I can think of, including putting some special code in sysctl to handle it, much in the same way that is used for some opaque sysctl variables. cheers luigi ndex: autoconf.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/autoconf.c,v retrieving revision 1.161 diff -u -r1.161 autoconf.c --- autoconf.c 28 Feb 2002 03:07:35 -0000 1.161 +++ autoconf.c 9 Mar 2002 11:57:21 -0000 @@ -238,8 +238,6 @@ } SYSINIT(cpu_rootconf, SI_SUB_ROOT_CONF, SI_ORDER_FIRST, cpu_rootconf, NULL) -u_long bootdev = 0; /* not a dev_t - encoding is different */ - #if defined(NFSCLIENT) && defined(NFS_ROOT) && !defined(BOOTP_NFSROOT) static int Index: machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.501 diff -u -r1.501 machdep.c --- machdep.c 8 Mar 2002 14:31:12 -0000 1.501 +++ machdep.c 9 Mar 2002 12:13:55 -0000 @@ -985,6 +985,10 @@ SYSCTL_INT(_machdep, CPU_WALLCLOCK, wall_cmos_clock, CTLFLAG_RW, &wall_cmos_clock, 0, ""); +u_long bootdev; /* not a dev_t - encoding is different */ +SYSCTL_ULONG(_machdep, OID_AUTO, bootdev, + CTLFLAG_RD, &bootdev, 0, "Boot device (not in dev_t format)"); + /* * Initialize 386 and configure to run kernel */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 8:26:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 7184037B404 for ; Sat, 9 Mar 2002 08:26:08 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g29GQ8U24039; Sat, 9 Mar 2002 08:26:08 -0800 (PST) (envelope-from rizzo) Date: Sat, 9 Mar 2002 08:26:08 -0800 From: Luigi Rizzo To: arch@FreeBSD.ORG Subject: Re: For review: machdep.bootdev sysctl (for i386) Message-ID: <20020309082607.I21016@iguana.icir.org> References: <20020309042728.A21016@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020309042728.A21016@iguana.icir.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG And as a followup, attached is a patch for sysctl(8) to parse the information. Again it can be cleaned up a little bit by making machdep.bootdev opaque, but that is purely a stylistic issue -- in the end, finding the proper parsing routine always involves a string comparison. Note that this is only valid for the i386 so I will make this code conditionally compiled if it ever gets committed. cheers luigi On Sat, Mar 09, 2002 at 04:27:28AM -0800, Luigi Rizzo wrote: > Looking at a way to determine the boot device from userland, > I have come to the conclusion that the most reasonable way is to > export to userland whatever information the kernel has (and this > is machine dependent, sorry!), and let some userland program ... Index: sysctl.c =================================================================== RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v retrieving revision 1.41 diff -u -r1.41 sysctl.c --- sysctl.c 25 Feb 2002 03:36:06 -0000 1.41 +++ sysctl.c 9 Mar 2002 15:20:52 -0000 @@ -404,6 +404,55 @@ } /* + * code to map a bootdev into a suitable string. + * Major numbers are mapped into names as in boot2.c + */ +struct _foo { + int majdev; + char *name; +} maj2name[] = { + 30, "ad", + 0, "wd", + 1, "wfd", + 2, "fd", + 4, "da", + -1, NULL /* terminator */ +}; + +#include +#include +static int +machdep_bootdev(u_long value) +{ + int majdev, unit, slice, part; + struct _foo *p; + + if (value & B_MAGICMASK != B_DEVMAGIC) { + printf("invalid (0x%08x)", value); + return 0; + } + majdev = B_TYPE(value); + unit = B_UNIT(value); + slice = B_SLICE(value); + part = B_PARTITION(value); + if (majdev == 2) { /* floppy, as known to the boot block... */ + printf("/dev/fd%d", unit); + return 0; + } + for (p = maj2name; p->name != NULL && p->majdev != majdev ; p++) ; + if (p->name != NULL) { /* found */ + if (slice == WHOLE_DISK_SLICE) + printf("/dev/%s%d%c", p->name, unit, part); + else + printf("/dev/%s%ds%d%c", + p->name, unit, slice - BASE_SLICE + 1, part + 'a'); + } else + printf("unknown (major %d unit %d slice %d part %d)", + majdev, unit, slice, part); + return 0; +} + +/* * This formats and outputs the value of one variable * * Returns zero if anything was actually output. @@ -496,6 +545,8 @@ if (!nflag) printf("%s%s", name, sep); fmt++; + if (!strcmp(name, "machdep.bootdev")) + return machdep_bootdev(*(unsigned long *)p); val = ""; while (len >= sizeof(long)) { if(*fmt == 'U') To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 8:32:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 4464537B404 for ; Sat, 9 Mar 2002 08:32:21 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g29GWJH24084; Sat, 9 Mar 2002 08:32:19 -0800 (PST) (envelope-from rizzo) Date: Sat, 9 Mar 2002 08:32:19 -0800 From: Luigi Rizzo To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Proposed patch: kern.bootdev* sysctl variables Message-ID: <20020309083219.J21016@iguana.icir.org> References: <20020308020009.A6535@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 08, 2002 at 12:59:40PM -0500, Garance A Drosihn wrote: ... > My machines tend to have scsi drives (and some of them have only > scsi hard drives), and I can also boot off of CD's. If something > like this is added, I think it pretty much has to give the correct > answer in all cases. If not, it should give a helpful clue, but there are some undetectable cases, such as when you boot from a CD using the floppy emulation in the bios... I have posted some code which is supposed to recognize the values set by boot2 . I have tried it (without a /boot/loader) from floppy and IDE hard disk (they are correctly recognised), CD in floppy emulation (recognised as floppy, as it should), etherboot (it correctly prints that the information is invalid). If you can try it from some other sources, maybe we can extend the cases that are recognised. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 12:34:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id BEDF637B404; Sat, 9 Mar 2002 12:34:44 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g29KYhVu137732; Sat, 9 Mar 2002 15:34:43 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Sat, 9 Mar 2002 15:34:42 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Fix for login.c, added questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:57 PM -0500 3/9/02, Garance A Drosihn wrote to freebsd-audit: >In my testing, the simple fix is: > >Index: login.c Reading thru login.c, it seems to me that we should probably consider some other changes too. One thing I noticed, for instance, is that login.c tries to setup a 300-second timeout, but apparently that timeout is masked off somewhere inside the auth_pam() processing. So, if a person types in a login name, a wrong password, types in the same login name and then just sits in the next password prompt, the session (apparently) never times out. Or at least it doesn't seem to have timed out for me in the more than 20 minutes I've left it sitting there on a console login. One thing the code tries to do is avoid a syslog message for the case of: login myid wrong password login myid correct password My claim is that this goal complicates the code enough that it also opens up some subtle opportunities for nefarious souls to be guessing passwords without syslog messages occurring. For one, it means you have to delay writing the syslog message at least until you read in the new userid, which is under the control of the very user who (perhaps) is trying to do something nasty. Do people think we could drop the nice idea of avoiding the syslog message in the above situation, and just always write out the syslog message right when we know the password is wrong? That will increase the number of syslog messages, which might alarm some users, but I think it's safer. Perhaps we could avoid that alarm by also writing out a syslog message if the session gives the correct password for a userid after having given a failed password. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 12:44:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 3FA8237B400 for ; Sat, 9 Mar 2002 12:44:23 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 2F3355348; Sat, 9 Mar 2002 21:44:21 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Fix for login.c, added questions References: From: Dag-Erling Smorgrav Date: 09 Mar 2002 21:44:20 +0100 In-Reply-To: Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn writes: > Reading thru login.c, it seems to me that we should probably > consider some other changes too. One thing I noticed, for > instance, is that login.c tries to setup a 300-second timeout, > but apparently that timeout is masked off somewhere inside the > auth_pam() processing. OpenPAM's standard conversation function uses a 180-second timeout for prompts, but it should restore the previous signal handlers and mask and restart any previously running timer. It's conceivable that there is a bug in that code, though. Take a look at src/contrib/openpam/lib/openpam_ttyconv.c and see if you spot any glaring errors. > Do people think we could drop the nice idea of avoiding the > syslog message in the above situation, and just always write > out the syslog message right when we know the password is > wrong? That will increase the number of syslog messages, > which might alarm some users, but I think it's safer. I totally agree. It's just not worth the added complexity. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 14:24:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 49D3037B402 for ; Sat, 9 Mar 2002 14:24:32 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g29MORVu016212 for ; Sat, 9 Mar 2002 17:24:27 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sat, 9 Mar 2002 17:24:26 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Increasing the size of dev_t and ino_t Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is something I've mentioned before, but reviewing the freebsd summit notes reminded me of it once again. The change itself is simple, but it would be disruptive enough that we can only consider it as part of a major release (such as the upcoming 5.0). Should we increase the size of dev_t and ino_t? Right now, both of them are unsigned 32-bit values. I shall claim that both of those are too small, or at least they WILL be too small by the time 6.0 rolls out. dev_t indicates the "device number" that a file is on, and and ino_t is the inode within that device. These are the st_dev and st_ino fields in 'struct stat'. At the summit, it was stated that UFS2 should (hopefully) be available for 5.0-release, and that it will be a 64-bit filesystem. If that is true, then it is certainly plausible that a single filesystem will see more than a 32-bit-ints-worth of inodes. And the hard-drive makers are also doing their best to produce huge hard disks. At the same time, we're seeing distributed file systems like AFS (or, more to the point, openAFS and ARLA). The nature of those filesystems are that you will mount many devices which might all be available at the same time. For those who are familiar with AFS, I would claim that every AFS volume should be a separate device (as far as st_dev in 'struct stat' is concerned), and if that is true than we can certainly end up with more than a 16-bit-ints-worth of devices, and probably more than a 32-bit- ints worth. I know the field is already a 32-bit int there, but the significance of my observation is that we can't just increase the size of st_ino and decrease the size of st_dev. I think that st_dev has to remain at *least* as large as it already is, and that we need to increase st_ino as well. Perhaps we only need to do this for the newer, 64-bit platforms. (perhaps we already are doing it there?). But I thought I would bring the topic up and see what others thought about it. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 14:36: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 4A2B237B402 for ; Sat, 9 Mar 2002 14:36:03 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g29MZgBo027967; Sat, 9 Mar 2002 23:35:43 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Your message of "Sat, 09 Mar 2002 17:24:26 EST." Date: Sat, 09 Mar 2002 23:35:42 +0100 Message-ID: <27966.1015713342@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >Should we increase the size of dev_t and ino_t? Right now, both >of them are unsigned 32-bit values. I shall claim that both of >those are too small, or at least they WILL be too small by the >time 6.0 rolls out. By dev_t I guess you mean the userland version of it (udev_t): the combined major and minor number. With DEVFS and properly written drivers, this field can be randomly assigned and will have no practical importance to the kernel. This is the direction we should move. The only argument I know for expanding it would be to make the slight hack used to hide the dictomy between the dev_t (a pointer) and the userland (u)dev_t (an integer) simpler on 64bit archs. The real solution would be to fix the software which makes bogus assumptions when reading kernel memory. >At the summit, it was stated that UFS2 should (hopefully) be >available for 5.0-release, and that it will be a 64-bit filesystem. UFS2 will have 64 bit inode numbers and will consequently very much like to have ino_t be 64bit. Traditionally (ie: "lex off_t") this means defining the relevant number of new syscalls (stat & fstat I think) so that we can still execute older programs. Summary: ino_t should be 64bit. dev_t should be uintptr_t or dev_t be renamed in the kernel. When is not really important since it will not be a backwards flag day, only a forwards flag day. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 15: 0:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 7A42737B416 for ; Sat, 9 Mar 2002 15:00:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020309230014.GKZR1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Sat, 9 Mar 2002 23:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA55417; Sat, 9 Mar 2002 14:42:55 -0800 (PST) Date: Sat, 9 Mar 2002 14:42:54 -0800 (PST) From: Julian Elischer To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG dev_t will not exist in 6.0 On Sat, 9 Mar 2002, Garance A Drosihn wrote: > This is something I've mentioned before, but reviewing the freebsd > summit notes reminded me of it once again. The change itself is > simple, but it would be disruptive enough that we can only consider > it as part of a major release (such as the upcoming 5.0). > > Should we increase the size of dev_t and ino_t? Right now, both > of them are unsigned 32-bit values. I shall claim that both of > those are too small, or at least they WILL be too small by the > time 6.0 rolls out. > > dev_t indicates the "device number" that a file is on, and and > ino_t is the inode within that device. These are the st_dev > and st_ino fields in 'struct stat'. > > At the summit, it was stated that UFS2 should (hopefully) be > available for 5.0-release, and that it will be a 64-bit filesystem. > If that is true, then it is certainly plausible that a single > filesystem will see more than a 32-bit-ints-worth of inodes. > And the hard-drive makers are also doing their best to produce > huge hard disks. > > At the same time, we're seeing distributed file systems like AFS > (or, more to the point, openAFS and ARLA). The nature of those > filesystems are that you will mount many devices which might all > be available at the same time. For those who are familiar with > AFS, I would claim that every AFS volume should be a separate > device (as far as st_dev in 'struct stat' is concerned), and if > that is true than we can certainly end up with more than a > 16-bit-ints-worth of devices, and probably more than a 32-bit- > ints worth. I know the field is already a 32-bit int there, but > the significance of my observation is that we can't just increase > the size of st_ino and decrease the size of st_dev. I think that > st_dev has to remain at *least* as large as it already is, and > that we need to increase st_ino as well. > > Perhaps we only need to do this for the newer, 64-bit platforms. > (perhaps we already are doing it there?). But I thought I would > bring the topic up and see what others thought about it. > > -- > Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu > Senior Systems Programmer or gad@freebsd.org > Rensselaer Polytechnic Institute or drosih@rpi.edu > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 16: 3:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 5F7F937B405 for ; Sat, 9 Mar 2002 16:03:11 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2A039Vu165060; Sat, 9 Mar 2002 19:03:09 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <27966.1015713342@critter.freebsd.dk> References: <27966.1015713342@critter.freebsd.dk> Date: Sat, 9 Mar 2002 19:03:08 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:35 PM +0100 3/9/02, Poul-Henning Kamp wrote: >In message , Garance A Drosihn writes: > >>Should we increase the size of dev_t and ino_t? Right now, both >>of them are unsigned 32-bit values. I shall claim that both of >>those are too small, or at least they WILL be too small by the >>time 6.0 rolls out. > >By dev_t I guess you mean the userland version of it (udev_t): the >combined major and minor number. Yes. The field in the 'struct stat' returned from stat(). Userland, posix, etc. The struct is supposed to include fields named st_dev and st_ino, of type dev_t and ino_t. >With DEVFS and properly written drivers, this field can be >randomly assigned and will have no practical importance to the >kernel. This is the direction we should move. > >The only argument I know for expanding it would be to make the >slight hack used to hide the dictomy between the dev_t (a pointer) >and the userland (u)dev_t (an integer) simpler on 64bit archs. I don't see how this would work for OpenAFS. By that I mean that I do not know how the dev_t-pointer that you're talking about is used when implementing something like OpenAFS or ARLA support. I'm afraid I'm only familiar with userland programming, and your answer is from the kernel point of view... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 16: 4:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id D279C37B400 for ; Sat, 9 Mar 2002 16:04:13 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2A04CVu069394; Sat, 9 Mar 2002 19:04:12 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Sat, 9 Mar 2002 19:04:11 -0500 To: Julian Elischer From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:42 PM -0800 3/9/02, Julian Elischer wrote: >dev_t will not exist in 6.0 Why would it not exist (the user-land type, for fields returned by the stat() call) in 6.0? I'm thinking of a change at the userland level, not the kernel level. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 20:56:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 0B93F37B404 for ; Sat, 9 Mar 2002 20:56:38 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g2A4u2j01429; Sat, 9 Mar 2002 20:56:02 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203100456.g2A4u2j01429@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Luigi Rizzo Cc: arch@freebsd.org Subject: Re: For review: machdep.bootdev sysctl (for i386) In-reply-to: Your message of "Sat, 09 Mar 2002 04:27:28 PST." <20020309042728.A21016@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Mar 2002 20:56:02 -0800 From: Michael Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Looking at a way to determine the boot device from userland, > I have come to the conclusion that the most reasonable way is to > export to userland whatever information the kernel has (and this > is machine dependent, sorry!), and let some userland program > (getbootdev(1)) convert it into a reasonable device name. What do you mean by "boot device"? The device from which the initial bootstrap was loaded? The device from which the loader was loaded? The device from which the kernel was loaded? There's really no such thing. > In the i386 case, the relevant information is in the "bootdev" > variable, defined in i386/i386/autoconf.c and initialized > in i386/i386/locore.s This is unreliable; it's usually but not always the BIOS unit number for the "current" disk, which may or may not be any of the above "boot devices". > In the Alpha case, there is no "bootdev" variable, so I need > feedback from Alpha experts on this. There is no way (that I am aware of) to extract the SRM name of the booted device. > Unless someone can suggest a better way (i.e. more general > and as little intrusive -- we are talking about a 3-line change > here!) I would like to commit this simple patch, moving bootdev > (which is currently written in locore.s and unused otherwise) to > machdep.c where the SYSCTL hook exports it. I think that this is not a good way to do things. Exporting this number is not useful, and based on my current reservations, I would strongly oppose any attempt to use it for anything. > As for the userland program to parse machdep.bootdev, for the time > being i am going to write it as part of the picobsd "tinyware", > pending suggestions on the best place to put it. I can't imagine how you plan to do this and make it reliable, since there is no mapping from BIOS unit numbers to BSD devices. In almost any case you are likely to care about, the "boot device" is also the root device. Detecting, let alone doing anything useful about, the other cases is IME an impossible proposition. = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 22:39:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id DC76A37B402 for ; Sat, 9 Mar 2002 22:39:29 -0800 (PST) Received: from pool0032.cvx22-bradley.dialup.earthlink.net ([209.179.198.32] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16jwzP-0004Fl-00; Sat, 09 Mar 2002 22:39:27 -0800 Message-ID: <3C8AFF8E.4B4C6940@mindspring.com> Date: Sat, 09 Mar 2002 22:39:10 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > This is something I've mentioned before, but reviewing the freebsd > summit notes reminded me of it once again. The change itself is > simple, but it would be disruptive enough that we can only consider > it as part of a major release (such as the upcoming 5.0). > > Should we increase the size of dev_t and ino_t? Right now, both > of them are unsigned 32-bit values. I shall claim that both of > those are too small, or at least they WILL be too small by the > time 6.0 rolls out. The limiting factor for these is NFS. The ino_t is limited by the ondisk structure. Note that the dev_t limitation is antiquated... but so is the idea of "fixing" it. With devfs, tonly the fact that device lookups still go through specfs makes major/minor numbers relevent at all. Their point was to provide a rendesvous that allowed conversion from an FS reference to a device instance reference. However, we can do that now, without using major or minor values, merely by using the name-to-vnode conversion in devfs. > At the summit, it was stated that UFS2 should (hopefully) be > available for 5.0-release, and that it will be a 64-bit filesystem. > If that is true, then it is certainly plausible that a single > filesystem will see more than a 32-bit-ints-worth of inodes. > And the hard-drive makers are also doing their best to produce > huge hard disks. You won't be able to export these via NFS, unless to have a 64 bit file instance to 32 bit reference instance conversion, and limit the number of open files to 2^32 simultaneous opens. Of course, doing that will add a significant reverse-lookup penalty for NFS handles, and for conversion of multiple name references into a single handle reference. > Perhaps we only need to do this for the newer, 64-bit platforms. > (perhaps we already are doing it there?). But I thought I would > bring the topic up and see what others thought about it. Check the NFSv4 RFC... and then check for an implementation in FreeBSD. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 22:42:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id B6F0D37B400 for ; Sat, 9 Mar 2002 22:42:12 -0800 (PST) Received: from pool0032.cvx22-bradley.dialup.earthlink.net ([209.179.198.32] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16jx1w-0005pv-00; Sat, 09 Mar 2002 22:42:04 -0800 Message-ID: <3C8B002B.D42A8572@mindspring.com> Date: Sat, 09 Mar 2002 22:41:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <27966.1015713342@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > >By dev_t I guess you mean the userland version of it (udev_t): the > >combined major and minor number. > > Yes. The field in the 'struct stat' returned from stat(). Userland, > posix, etc. The struct is supposed to include fields named st_dev > and st_ino, of type dev_t and ino_t. Note also that POSIX requires them to be atomic types. So "long long" need not apply, FWIW. If you insist on going down this path, I'd like to see a binary compatability strategy as the first output of the project. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 22:43:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id A87CC37B400; Sat, 9 Mar 2002 22:43:10 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2A6hAq29071; Sat, 9 Mar 2002 22:43:10 -0800 (PST) (envelope-from rizzo) Date: Sat, 9 Mar 2002 22:43:10 -0800 From: Luigi Rizzo To: Michael Smith Cc: arch@FreeBSD.ORG Subject: Re: For review: machdep.bootdev sysctl (for i386) Message-ID: <20020309224310.A28779@iguana.icir.org> References: <20020309042728.A21016@iguana.icir.org> <200203100456.g2A4u2j01429@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203100456.g2A4u2j01429@mass.dis.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike, I am not claiming that bootdev gives the correct answer in 100% of the cases. As you correctly notice, there is probably not a "perfect" solution. However, _having tried_ to use it (with the sysctl patch that I posted as a followup, which does essentially the same mapping that is in boot/i386/boot2/boot2.c and presumably was in the ancient i386/i386/autoconf.c), I have to disagree with you on the usefulness of this number. It gives some reasonable information in some common cases, e.g. when you boot off a floppy or a hard disk/CompactFlash slice, and i think it is a big improvement over the current situation where we can only do a blind guess having no information at all. I am not suggesting to use this method as a standard piece of /etc/rc, just make this info available for those users who might have a need for it (and know of its limitations). As I said, if anyone has a better way to do this I'll be glad to hear that. As for the cases I care about (booting PicoBSD, but that would also apply to install disks to make another example), the root device comes from MFS and it is obviously not the root device. So, to summarise: comments received, thanks, we agree on some things, disagree on some others (and I have shown you examples why), and since the gist of my proposal was to export a single kernel variable through sysctl which does not expose any security risk, I do not believe that people should be too upset by this change. For what matters, we already export lots of stuff (such as machdep.bootinfo, debug.boothowto, debug.sizeof.*). of questionable usefulness (to me, but then others might have some use for this information). cheers luigi On Sat, Mar 09, 2002 at 08:56:02PM -0800, Michael Smith wrote: > > Looking at a way to determine the boot device from userland, > > I have come to the conclusion that the most reasonable way is to > > export to userland whatever information the kernel has (and this > > is machine dependent, sorry!), and let some userland program > > (getbootdev(1)) convert it into a reasonable device name. > > What do you mean by "boot device"? > > The device from which the initial bootstrap was loaded? The device from > which the loader was loaded? The device from which the kernel was loaded? > > There's really no such thing. > > > In the i386 case, the relevant information is in the "bootdev" > > variable, defined in i386/i386/autoconf.c and initialized > > in i386/i386/locore.s > > This is unreliable; it's usually but not always the BIOS unit number for > the "current" disk, which may or may not be any of the above "boot > devices". > > > In the Alpha case, there is no "bootdev" variable, so I need > > feedback from Alpha experts on this. > > There is no way (that I am aware of) to extract the SRM name of the > booted device. > > > Unless someone can suggest a better way (i.e. more general > > and as little intrusive -- we are talking about a 3-line change > > here!) I would like to commit this simple patch, moving bootdev > > (which is currently written in locore.s and unused otherwise) to > > machdep.c where the SYSCTL hook exports it. > > I think that this is not a good way to do things. Exporting this number > is not useful, and based on my current reservations, I would strongly > oppose any attempt to use it for anything. > > > As for the userland program to parse machdep.bootdev, for the time > > being i am going to write it as part of the picobsd "tinyware", > > pending suggestions on the best place to put it. > > I can't imagine how you plan to do this and make it reliable, since there > is no mapping from BIOS unit numbers to BSD devices. In almost any case > you are likely to care about, the "boot device" is also the root device. > > Detecting, let alone doing anything useful about, the other cases is IME > an impossible proposition. > > = Mike > > -- > To announce that there must be no criticism of the president, > or that we are to stand by the president, right or wrong, is not > only unpatriotic and servile, but is morally treasonable to > the American public. - Theodore Roosevelt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 9 23:20:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id BECE337B419 for ; Sat, 9 Mar 2002 23:20:16 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020310072016.PBYR1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Sun, 10 Mar 2002 07:20:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA56946; Sat, 9 Mar 2002 23:04:09 -0800 (PST) Date: Sat, 9 Mar 2002 23:04:07 -0800 (PST) From: Julian Elischer To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG it will be a random unique number that will be valid for that boot but may be completely different after the next boot. On Sat, 9 Mar 2002, Garance A Drosihn wrote: > At 2:42 PM -0800 3/9/02, Julian Elischer wrote: > >dev_t will not exist in 6.0 > > Why would it not exist (the user-land type, for fields returned > by the stat() call) in 6.0? I'm thinking of a change at the > userland level, not the kernel level. > > -- > Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu > Senior Systems Programmer or gad@freebsd.org > Rensselaer Polytechnic Institute or drosih@rpi.edu > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message