mount_unionfs(8)
What is the state of unionfs? There was apparently a big reimplementation of it that was merged in when 7 was -CURRENT, but there is absolutely no mention of this in the man page, which is dated November 30, 2006, and has a big scary warning: THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. BATTERIES NOT INCLUDED. This leaves me highly confused. Was the man page really never updated in the last 7+ years? Is unionfs as it is in 10.0-RELEASE stable and functional? If the man page really is outdated and the big scary warning is not appropriate, what are the valid options, and what are the known bugs (if any) that should be noted in the man page? ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
Re: docs/188786: Bug in inet(3) man page (inet_aton())
On 05/23/2014 04:47 AM, Benjamin Kaduk wrote: > Hi Michael, > > Sorry it took me so long to reply. I had a lot of catching up to do after > BSDCan... > > On Sat, 17 May 2014, Michael Kerrisk (man-pages) wrote: > >> I think that what makes the page a little confusing is that it uses >> both terms "Internet address" and "network address" without making it >> clear that they are synonymous (and thus leaving the potential for the >> reader to think they are not). This might not normally be problematic, >> but given that the page is also talking about the 'network' and 'host' >> components of the address, there is scope for confusion. Not a big >> thing, I guess, but FWIW that's the confusion that I tried to avoid in >> the Linux man page by using the term "binary address"; see >> http://man7.org/linux/man-pages/man3/inet.3.html#DESCRIPTION > > I see how there could be confusion, and we could probably do better. > I'll put taking a look at this man page in general on my todo list, but > leave this PR cloesd for now. > (I do remember that a lot of the functional parts of classful addressing > have actually been removed from FreeBSD, but not whether this part in > particular was removed. I'll have to check.) Okay. > Thanks again for the submission, it's always good to get suggestions. You're welcome. Thanks for following up, Ben. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
Re: mount_unionfs(8)
No, it's not stable and it can easily make local DOS, even from jail, if user-mounts allowed. Until sych things are fixed, let's that scary text be there :) Regards, Alexander Yerenkow 24 мая 2014 г. 12:24 пользователь "Andrew Berg" < aberg...@my.hennepintech.edu> написал: > What is the state of unionfs? There was apparently a big reimplementation > of it > that was merged in when 7 was -CURRENT, but there is absolutely no mention > of > this in the man page, which is dated November 30, 2006, and has a big scary > warning: > THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) > AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN > RISK. BEWARE OF DOG. SLIPPERY WHEN WET. BATTERIES NOT INCLUDED. > > This leaves me highly confused. Was the man page really never updated in > the > last 7+ years? Is unionfs as it is in 10.0-RELEASE stable and functional? > If > the man page really is outdated and the big scary warning is not > appropriate, > what are the valid options, and what are the known bugs (if any) that > should be > noted in the man page? > ___ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org" > ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
Re: docs/188214: Manpage for fsck(8) doesn't say what happens when no -t or -T
On Fri, 23 May 2014 15:40:00 GMT Allan Jude wrote: > The following reply was made to PR docs/188214; it has been noted by GNATS. > > From: Allan Jude > To: bug-follo...@freebsd.org, r...@tristatelogic.com, > Tom Rhodes > Cc: > Subject: Re: docs/188214: Manpage for fsck(8) doesn't say what happens > when no -t or -T > Date: Fri, 23 May 2014 11:39:24 -0400 > > I have not checked the code to be sure, but from general usage I have > noticed that fsck(8) doesn't actually try to detect, or 'taste' the > partition, but only looks at /etc/fstab and if the type is not > specified, then returns the error. > > Suggesting that it 'attempts to detect' may give the wrong impression. > Someone would have to look at the source of fsck(8) to be sure. > So, in theory, an attempt to parse /etc/fstab would be an attempt to detect the type; however, my quick glance at the code showed no real parsing of fstab. But in my case, I followed to both the T and t flags, and just glanced at what was done would they not be specified. That was really as far as I got, and I attempted to use very generic language in case it only does one, or the other, or both. :) Reasonable? -- Tom Rhodes ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
Re: docs/188214: Manpage for fsck(8) doesn't say what happens when no -t or -T
The following reply was made to PR docs/188214; it has been noted by GNATS. From: Mark Linimon To: bug-follo...@freebsd.org Cc: Subject: Re: docs/188214: Manpage for fsck(8) doesn't say what happens when no -t or -T Date: Sat, 24 May 2014 12:11:17 -0500 - Forwarded message from Tom Rhodes - Date: Sat, 24 May 2014 12:32:04 -0400 From: Tom Rhodes To: Allan Jude Cc: freebsd-doc@FreeBSD.org Subject: Re: docs/188214: Manpage for fsck(8) doesn't say what happens when no -t or -T X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; x86_64-unknown-freebsd9.2) > Suggesting that it 'attempts to detect' may give the wrong impression. > Someone would have to look at the source of fsck(8) to be sure. So, in theory, an attempt to parse /etc/fstab would be an attempt to detect the type; however, my quick glance at the code showed no real parsing of fstab. But in my case, I followed to both the T and t flags, and just glanced at what was done would they not be specified. That was really as far as I got, and I attempted to use very generic language in case it only does one, or the other, or both. :) Reasonable? -- Tom Rhodes ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org" - End forwarded message - ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
request: help updating TASKQUEUE(9)
Hi, I've just added a new call to taskqueue - taskqueue_start_threads_pinned(). It's like taskqueue_start_threads(), but it takes a cpuid to pin the threads to. Would someone please help me with the manpage markup and wording? Thanks! -a ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
Re: docs/188214: Manpage for fsck(8) doesn't say what happens when no -t or -T
The following reply was made to PR docs/188214; it has been noted by GNATS. From: Benjamin Kaduk To: Tom Rhodes Cc: Allan Jude , bug-follo...@freebsd.org Subject: Re: docs/188214: Manpage for fsck(8) doesn't say what happens when no -t or -T Date: Sat, 24 May 2014 17:42:47 -0400 (EDT) On Sat, 24 May 2014, Tom Rhodes wrote: > So, in theory, an attempt to parse /etc/fstab would be > an attempt to detect the type; however, my quick glance > at the code showed no real parsing of fstab. But in > my case, I followed to both the T and t flags, and just > glanced at what was done would they not be specified. > That was really as far as I got, and I attempted to use > very generic language in case it only does one, or the > other, or both. :) When passed no device or path arguments, fsck just checks everything from the fstab; that's not very interesting for this question. Given a path argument and no type argument to use, fstab is parsed using getfsfile() or getfsspec() around line 204 of fsck.c. This will fail (well, barring special circumstances) if the argument is instead a device name. Given a device name argument and no type argument to use, after the fstab check above, fsck opens the device and uses ioctl() to get the disklabel and does some magic to grab the fstype from it. (See getfslab(), in fsck.c) So, I think there is a fair bit of autodetection that is attempted. -Ben ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
Re: request: help updating TASKQUEUE(9)
On Sat, 24 May 2014, Adrian Chadd wrote: Hi, I've just added a new call to taskqueue - taskqueue_start_threads_pinned(). It's like taskqueue_start_threads(), but it takes a cpuid to pin the threads to. Would someone please help me with the manpage markup and wording? Something like this? -BenIndex: share/man/man9/taskqueue.9 === --- share/man/man9/taskqueue.9 (revision 266330) +++ share/man/man9/taskqueue.9 (working copy) @@ -28,7 +28,7 @@ .\" .\" $FreeBSD$ .\" -.Dd January 24, 2014 +.Dd May 24, 2014 .Dt TASKQUEUE 9 .Os .Sh NAME @@ -68,6 +68,11 @@ .Fn taskqueue_create_fast "const char *name" "int mflags" "taskqueue_enqueue_fn enqueue" "void *context" .Ft int .Fn taskqueue_start_threads "struct taskqueue **tqp" "int count" "int pri" "const char *name" "..." +.Ft int +.Fo taskqueue_start_threads_pinned +.Fa "struct taskqueue **tqp" "int count" "int pri" "int cpu_id" +.Fa "const char *name" "..." +.Fc .Ft void .Fn taskqueue_set_callback "struct taskqueue *queue" "enum taskqueue_callback_type cb_type" "taskqueue_callback_fn callback" "void *context" .Ft void @@ -145,7 +150,14 @@ which the thread servicing the queue will be signaled that it should exit. .Pp Once a taskqueue has been created, its threads should be started using -.Fn taskqueue_start_threads . +.Fn taskqueue_start_threads +or +.Fn taskqueue_start_threads_pinned . +.Fn taskqueue_start_threads_pinned +takes a +.Va cpu_id +argument which will cause the threads which are started for the taskqueue +to be pinned to run on the given CPU. Callbacks may optionally be registered using .Fn taskqueue_set_callback . Currently, callbacks may be registered for the following purposes: ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
Re: request: help updating TASKQUEUE(9)
Yup! Thanks! -a On 24 May 2014 15:02, Benjamin Kaduk wrote: > On Sat, 24 May 2014, Adrian Chadd wrote: > >> Hi, >> >> I've just added a new call to taskqueue - >> taskqueue_start_threads_pinned(). It's like taskqueue_start_threads(), >> but it takes a cpuid to pin the threads to. >> >> Would someone please help me with the manpage markup and wording? > > > Something like this? > > -Ben ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
Re: docs/188214: Manpage for fsck(8) doesn't say what happens when no -t or -T
The following reply was made to PR docs/188214; it has been noted by GNATS. From: Tom Rhodes To: Benjamin Kaduk Cc: trho...@freebsd.org, allanj...@freebsd.org, bug-follo...@freebsd.org Subject: Re: docs/188214: Manpage for fsck(8) doesn't say what happens when no -t or -T Date: Sun, 25 May 2014 01:16:52 -0400 Hi Benjamin, On Sat, 24 May 2014 17:42:47 -0400 (EDT) Benjamin Kaduk wrote: > On Sat, 24 May 2014, Tom Rhodes wrote: > > > So, in theory, an attempt to parse /etc/fstab would be > > an attempt to detect the type; however, my quick glance > > at the code showed no real parsing of fstab. But in > > my case, I followed to both the T and t flags, and just > > glanced at what was done would they not be specified. > > That was really as far as I got, and I attempted to use > > very generic language in case it only does one, or the > > other, or both. :) > > When passed no device or path arguments, fsck just checks everything from > the fstab; that's not very interesting for this question. > > Given a path argument and no type argument to use, fstab is parsed using > getfsfile() or getfsspec() around line 204 of fsck.c. This will fail > (well, barring special circumstances) if the argument is instead a device > name. > > Given a device name argument and no type argument to use, after the fstab > check above, fsck opens the device and uses ioctl() to get the disklabel > and does some magic to grab the fstype from it. (See getfslab(), in > fsck.c) > > > So, I think there is a fair bit of autodetection that is attempted. Thanks for the deep dive - I was going to revisit this later (i.e.: actually step through the code more) if there was a real issue. Thanks for saving me the time! :) -- Tom Rhodes ___ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
