Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On 16/03/2011, at 4:14, Ben Kaduk wrote: >> is wise to others. It's a little bit of a pain on the implementation side, >> since you can't turn it on from newfs, but that isn't a serious obstacle. > > I suspect the consensus of people like -arch and -fs will be that the > burn-in time before it is considered sufficiently stable is be > measured in years. Which is a good reason to have a UI to set it :) Or maybe when you say "auto" it asks if you want it on or not. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220983 - head
On 24/04/2011, at 18:19, Andrey Chernov wrote:
> On Sun, Apr 24, 2011 at 09:23:08AM +, Alexander Motin wrote:
>> ATA device names in /etc/fstab or other places, make sure to update
>> them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
>> -where 'Y's are the sequential numbers for each type in order of
>> -detection, unless configured otherwise with tunables, see cam(4)).
>> +where 'Y's are the sequential numbers starting from zero for each type
>> +in order of detection, unless configured otherwise with tunables,
>> +see cam(4)).
>
> Is there any way to guess resulting 'Y' numbers _before_ booting new
> kernel? I have remote machine with console access almost impossible (very
> hard for me).
>
> It seems something like
> vfs.root.mountfrom="ufs:/dev/ada0s1a ufs:/dev/ada1s1a ..."
> (up to max channels) helps to find root, but what about other mounted
> disks?
The best way is to change to use GPT IDs (/dev/gptid/xxx) if you are on a GPT
system) or UFS IDs (/dev/ufsid/xxx) if you can't.
gpart list will show the GPTID (rawuuid) and dumpfs will show the UFS ID.
The following shell snippet will generate the UFS ID for a given FS.
getfsid() {
line=`dumpfs 2> /dev/null $1 | head | grep superblock\ location`
if [ $? -ne 0 ]; then
return 1
fi
# dumpfs doesn't print leading 0s
eval `echo $line | sed -nEe 's/superblock location.*id.*\[ (.*) (.*)\
]/printf %0x $((0x\1 << 32 | 0x\2))/p'`
}
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220983 - head
On 25/04/2011, at 6:55, Warner Losh wrote: >> The best way is to change to use GPT IDs (/dev/gptid/xxx) if you are on a >> GPT system) or UFS IDs (/dev/ufsid/xxx) if you can't. > > I've been running with ufs labels for a couple of years now, since the first > rumblings of this hit the streets. They work great no matter what the > underlying partitioning scheme. The one drawback is that if you have > multiple disks with the same labels, then the first one wins. Normally not a > problem, but when you have it, you need to ensure the right one is selected. > I avoid this problem by prefixing a hostname to the label... This is why I prefer IDs since they are nominally unique (UFS ones, GPTs damn well better be :) Although I concede it is rather annoying to work out which is which, or type them out manually.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220983 - head
On 26/04/2011, at 1:31, Warner Losh wrote: >> This is why I prefer IDs since they are nominally unique (UFS ones, GPTs >> damn well better be :) >> >> Although I concede it is rather annoying to work out which is which, or type >> them out manually.. > > For things like ZFS, UUIDs aren't so bad because it hides them. Yes, I use GPT with ZFS, it's good :) > For things like /etc/fstab, I prefer the named approach. This allows me to > survive a newfs on a partition if I have to without having to hack my > /etc/fstab. I have a large /tmp partition at times, and it gets newfs'd if > there's a bad problem... Yeah, but.. IMHO if the installer supports it then it is dramatically less painful.. I haven't looked to see how hard it is to add, hopefully I will get some time to look RSN and it shouldn't be too difficult. FWIW the above shell snippet is found in a post [sys]install shell script I used for 6.x and later so it has had a bit of testing. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r207472 - in head/sys: conf dev/ath/ath_hal/ar5212
On 02/05/2010, at 2:06 AM, Warner Losh wrote: > Unfortunately, this condition is impossible to detect at runtime > without MIPS specific ifdefs. Rather than cast an overly-broad net > like Linux/OpenWRT dues (which enables this workaround all the time on > MIPS32 platforms), we put this option in the kernel for just the > affected machines. Sam didn't like this aspect of the patch when he > reviewed it, and I'd love to hear sane proposals on how to fix it :) Could you do TUNABLE_INT in the MIPS code and TUNABLE_INT_FETCH in ath_hal? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r207472 - in head/sys: conf dev/ath/ath_hal/ar5212
On 02/05/2010, at 11:17 AM, M. Warner Losh wrote:
> : Could you do TUNABLE_INT in the MIPS code and TUNABLE_INT_FETCH in ath_hal?
>
> How is that better than a kernel option? The only place this would
> ever happen is atheros AR71xx SoC. It isn't like some of the Atheros
> 71xx SoCs would have it and some wouldn't.
OK.
> And besides, kenv has to be compiled into the kernel on MIPS these
> days...
Ahh that makes a tunable fairly useless then :)
> The only thing close to an idea I've had is to add:
>
> __weak int
> ath_needs_dma_war()
> {
> return 0;
> }
>
> and have this in the mips:
>
> int needs_ath_dma_war = 0;
> __weak int ath_needs_dma_war()
> {
> return needs_ath_dma_war;
> }
>
> and set it to 1 in the AR71xx CPU initialization. But that seemed
> kind of lame...
It does have the advantage of not requiring the user to do anything which is
nice even if it's clunky looking.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf
On 11/06/2011, at 22:37, Robert Watson wrote: > While it seems like memory is "free" these days, that's not really the case. > The base kernel footprint is quite observable in VM configurations, where > it's common to configure quite low memory footprints -- 256M, 512M, etc, in > order to improve VM density. Speaking of memory - does loading something as a module impact on memory consumption by the kernel (one way or the other)? ie would it be a penalty to load stuff as a module, especially if you start loading 10's of them. (That said, I'm a fan of a small base kernel + modules for the many reasons listed in this thread :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf
On 12/06/2011, at 20:51, Alexey Dokuchaev wrote: >> I think trasz@ tried that and there is a problem. Loading modules on >> boot is very slow. If you try to load everything that GENERIC has as >> modules the boot will take forever. > > Perhaps then we need to come up with something more intelligent, i.e. do not > load everything trying to get maximum coverage of users' hardware, but > load only required bits based on what we see on PCI bus (roughly speaking). Now the tricky part is extracting supported device IDs from drivers in an automatic fashion :) I imagine some symbol magic could be done for the general case so a tool could extract the IDs & the bus type (so it could work for PCI & USB which covers about 99.9% of the hardware in question). ISTR there a few modules which call some blob to determine if the module is supported but I think it's quite rare (the 80/20 rule works for me here :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf
On 13/06/2011, at 7:46, Warner Losh wrote: >> ISTR there a few modules which call some blob to determine if the module is >> supported but I think it's quite rare (the 80/20 rule works for me here :) > > I've looked into this extensively. usb comes the closest right now, since > nearly all of its drivers use the right interface to match driver to device. > There is a standard structure people use. However, even it is impossible to > extract this data in a reliable automated fashion. Ideally, these tables > would move to their own section which could then be extracted by a tool to > see when to load it. This section would also need some additional metadata > in it so we know how to interpret the section. > > The situation with the PCI bus is much less uniform. While many drivers have > tables, these tables are all ad-hoc. There's no standard structure so > everybody invents their own. In addition to annotating the tables, you'd > have to regularize them all across all pci drivers. Doing this for 100+ > drivers is a bit tedious. Also, there are at least two cases where we have > to load two drivers to be sure that one of them attaches because there's > matching done outside of the normal plug and play identifiers (eg > vendor/device/function/subvendor/subdevice) in their probe routines. > PC Card has also had the standard structure and interface for many years. > When I tried to move this to PCI many years ago, I encountered a lot of > resistance that didn't make sense to me at the time (so I can't do it justice > now). This should tell you how long the problem has languished. It was the > primary motivator behind writing devd, but the pci resistance lead me to put > aside the problem for a while. I'll be happy to pick it back up, especially > if I can get some help going through all the drivers and tagging things > appropriately. I would be interested in helping, certainly with the mechanical changes. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r211983 - head/sbin/hastd
On 30/08/2010, at 9:50, Philip M. Gollucci wrote: >> MFC after: 2 weeks >> Obtained from: Wheel Systems Sp. z o.o. http://www.wheelsystems.com > Do you work for them or something ? > > The site's not in english It has an 'english version' link in the top right hand corner.. > > > -- > > 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C > Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 > VP Apache Infrastructure; Member, Apache Software Foundation > Committer,FreeBSD Foundation > Consultant, P6M7G8 Inc. > Sr. System Admin, Ridecharge Inc. > > Work like you don't need the money, > love like you'll never get hurt, > and dance like nobody's watching. > ___ > svn-src-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-all > To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" > -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Re: svn commit: r212964 - head/sys/kern
On 24/09/2010, at 24:28, Ken Smith wrote: > stuff. The *bulk* of people using -stable are less interested or > flat out not interested. And have no clue what crash dumps are, > may be challenged to notice partition-getting-full issues, etc. > > I'm open to having my mind changed about this if there is enough > push-back. Just saying I'm not there yet. I'd say people are uninterested in debugging right up until their system panics and they want to stop it doing that :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r212964 - head/sys/kern
On 25/09/2010, at 8:23, Peter Jeremy wrote: > savecore already has support for a 'minfree' file to prevent > crashdumps filling the crashdir. Maybe the default install should > include a minfree set to (say) 512MB. Or perhaps add maxcount and set it to 1 as well as minfree at 512Mb. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r225937 - in head: . release release/amd64 release/i386 release/ia64 release/pc98 release/powerpc release/scripts release/sparc64 usr.sbin usr.sbin/sysinstall
On 04/10/2011, at 8:41, Craig Rodrigues wrote: > Can bsdinstall be used as a drop-in replacement for > sysinstall when run with the "SCRIPT SYNTAX" batch mode? > If not, how much code would need to be added to bsdinstall? Or, is there > some other utility, such as something from the PC-BSD suite of scripts, > that can be used as a drop-in replacement for sysinstall in "SCRIPT > SYNTAX" mode? No it can't, but speaking as someone who used this feature in sysinstall… Good riddance :) I wrote a shell script which does an install itself (i.e. no bsdinstall - which is just [mostly] a shell script). It is 200 lines, a fair chunk of which is pre-canned stuff to go into rc.conf, loader.conf, etc.. http://www.gsoft.com.au/~doconnor/install-os.sh I also modified the rc.local script the installer uses to add an option to call my script. > Thanks. > -- > Craig Rodrigues > rodr...@crodrigues.org > ___ > svn-src-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-all > To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" > -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r225937 - in head: . release release/amd64 release/i386 release/ia64 release/pc98 release/powerpc release/scripts release/sparc64 usr.sbin usr.sbin/sysinstall
On 04/10/2011, at 17:09, Craig Rodrigues wrote: > However, I have seen at least two places which have written > Jumpstart/Kickstart > based installers based on sysinstall. This use case is not uncommon. > For example, using an install.cfg was documented here, and people > have followed it: > http://www.freebsd.org/doc/en/articles/pxe/article.html > > > If in the 10.0 timeframe, if we can provide something (bsdinstall, > pc-sysinstall, whatever) that has some compatibility with the old > sysinstall scripted syntax, that would be nice for users who have > built installers based on this stuff. > I suspect this would be problematic because bsdinstall is architected differently to sysinstall and the later's scripting is based on calling various C functions :( Also things like dist names are different.. Don't let me stop you writing it though ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 19/06/2013, at 2:18, Andre Oppermann wrote: >> I don't find it unreasonable to ask developers to install the port. >> And for users it seems all they need is something like portsnap for base. >> Portsnap already distributes ports svn so it shouldn't be too hard to >> adapt it for base. And the extra layer it adds is very convenient. Apart >> from a bigger than usual update maybe, portsnap users never even noticed >> it was switched from cvs to svn at some point. > > Installing SVN from ports is very painful because of the huge dependency > chain it carries, with the largest being Python and Perl IIRC. Perhaps there should be an svnlite port then, or svnstatic or similar. If an svnstatic port was installed as a package it would have no run time dependencies, so not huge chains of stuff to install. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 20/06/2013, at 23:03, Julian Elischer wrote: >> And do you think that the sort of user who is sufficiently engaged with the >> project to do this is the sort of user who would not be willing to do so if >> it meant installing the subversion port? If so, then there is a clear case >> for svnlite. > > I think that it lowers the barrier.. once you start bringing ports into the > picture you start running the risk of port revision hell. If there is a statically linked port & corresponding package then the barrier is almost as low, but has a few other advantages that other people have listed. That approach has a small footprint (binary + man page), is always up to date (so the VCS infrastructure is not tied to the earliest version of SVN) and doesn't have any dependencies. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r252032 - head/sys/amd64/include
On 25/06/2013, at 12:54, Bruce Evans wrote: >> - run a daemon every few minutes to fetch all the counters, so that >> the native-sized counters are in no danger of overflowing on systems >> that don't run statistics programs often enough to fetch the counters >> to actually use. > > There is at least 1 counter decrement (add -1) in tcp, so the native counters > need to be signed. You could convert decrements into an increment of a separate counter and then subtract that value from the others when collecting them all. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On 1 May 2014, at 0:18, Ian Lepore wrote: >> /dev/full is similar to /dev/zero except it always returns >> ENOSPC when you attempt to write to it. >> > > For some reason this reminded me of something I've been wanting for a > while but never get around to writing... /dev/ones, it's just > like /dev/zero except it returns 0xff bytes. Useful for dd'ing to wipe > out flash-based media. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/79421 :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r260486 - head/etc/defaults
On 10 Jan 2014, at 2:48, Adrian Chadd wrote: > Depends if you're thinking locally or globally. > > Locally - for nfs? not a big deal. > > Globally - NFS, ZFS, GELI, geom/cam, NIC, etc.. suddenly your machine > could default to having a couple thousand worker threads just for a > HBA and a 10GE NIC. That's a little nuts. > Most of those aren't paid unless you actually enable the thing in question. Same with this change, if you aren't using NFS you don't pay the cost. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r297897 - in head/usr.bin: . resizewin
Also, it's not functionally identical to the xterm version which could cause an issue for some users. -- Daniel O'Connor "The nice thing about standards is there are so many to choose from." - Andrew Tanenbaum > On 4 May 2016, at 07:58, Conrad Meyer wrote: > >> On Tue, May 3, 2016 at 2:53 PM, Gleb Smirnoff wrote: >> On Tue, Apr 12, 2016 at 05:42:54PM -0700, Conrad Meyer wrote: >> C> On Tue, Apr 12, 2016 at 5:30 PM, Conrad E. Meyer wrote: >> C> > Log: >> C> > Add a small tool, resizewin(1), to query terminal for window size >> C> >> C> Whoops. The commit message should have included this blurb from the >> C> phabricator review: >> C> >> C> This tool is a smaller, less featured version of resize from the >> xterm port. >> C> >> C> It's very useful when accessing systems via serial console that >> C> don't run X (e.g. dev boxes). >> >> Are there any good reasons not to call it resize then? Those who have >> xterm installed would have it overriden with /usr/local/bin/resize. > > Hi, > > I don't think it's a good idea to name different binaries the same > thing and rely on PATH ordering to pick the right one. And it would > introduce a conflict for LOCALBASE=/usr. > > Best, > Conrad ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r236380 - head/sys/vm
On 01/06/2012, at 15:38, Sergey Kandaurov wrote: > Well, we already have more powerful vm.swap_info, so > I see no reason to add yet another one to do the same thing > (but now with a human interface). > Probably sysctl(8) should be enhanced to parse it instead. There are already sysctls which have duplicate information, eg kern.geom.conf* (text, XML & dot versions of the same data) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r237223 - head/sys/dev/fb
On 18/06/2012, at 19:04, Gennady Proskurin wrote:
>> Modified: head/sys/dev/fb/fbreg.h
>> ==
>> --- head/sys/dev/fb/fbreg.h Mon Jun 18 07:43:23 2012(r237222)
>> +++ head/sys/dev/fb/fbreg.h Mon Jun 18 07:54:10 2012(r237223)
>> @@ -39,6 +39,7 @@
>> static __inline void
>> copyw(uint16_t *src, uint16_t *dst, size_t size)
>> {
>> +size >>= 1;
>> while (size--)
>> *dst++ = *src++;
>> }
>
> If size is odd, this does not copy the last byte. Not sure, whether this is
> intended.
Add
KASSERT(size & 0x1 == 0, ("odd size copy"));
before
size >>= 1;
:)
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r242520 - head/sys/kern
On 04/11/2012, at 7:45, Konstantin Belousov wrote: > On Sun, Nov 04, 2012 at 01:08:18AM +0400, Gleb Smirnoff wrote: >> On Sat, Nov 03, 2012 at 01:35:20PM -0700, Alfred Perlstein wrote: >> A> Author: alfred >> A> Date: Sat Nov 3 18:21:40 2012 >> A> New Revision: 242520 >> A> URL: http://svn.freebsd.org/changeset/base/242520 >> A> >> A> Log: >> A> Retire MAXUSERS. >> A> >> A> Approved by: peter, meetBSD >> >> This mechanical rename to meaningless (from viewpoint of average >> operating system user) name is not a retirement. It is just a stupid >> rename. >> >> FreeBSD source tree isn't a place for stupid jokes. Please back this >> out. > > Seconded. Unfortunately, this cannot be reverted. At least r242520 shall > stay as is in repo. r242520 is actually.. Author: mckusick Date: Sat Nov 3 18:55:55 2012 UTC (12 hours, 6 minutes ago) Changed paths: 2 Log Message: When a file is first being written, the dynamic block reallocation (implemented by ffs_reallocblks_ufs[12]) relocates the file's blocks so as to cluster them together into a contiguous set of blocks on the disk. When the cluster crosses the boundary into the first indirect block, the first indirect block is initially allocated in a position immediately following the last direct block. Block reallocation would usually destroy locality by moving the indirect block out of the way to keep the data blocks contiguous. This change compensates for this problem by noting that the first indirect block should be left immediately following the last direct block. It then tries to start a new cluster of contiguous blocks (referenced by the indirect block) immediately following the indirect block. We should also do this for other indirect block boundaries, but it is only important for the first one. Suggested by: Bruce Evans MFC: 2 weeks ie it is a joke :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r242897 - head/release
On 12/11/2012, at 9:00, Glen Barber wrote: >> Since snapdir=visible is non-standard setting, will it be sensible to >> exclude .snap as well? (maybe also .git?) >> > > Yes, I think so. This was mentioned yesterday, but I had already sent > this patch for review. I do intend to exclude more dot-dirs. Why not just exclude '.??*' ? I doubt the source tree will ever grow a top level directory whose name starts with a dot. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Re: svn commit: r237223 - head/sys/dev/fb
On 20/06/2012, at 17:11, Gennady Proskurin wrote: > On Tue, Jun 19, 2012 at 05:27:11AM +, Poul-Henning Kamp wrote: >> In message <68fbe843-7337-4c90-b01f-e0caabb62...@gsoft.com.au>, "Daniel >> O'Conno >> r" writes: >> >>>> If size is odd, this does not copy the last byte. Not sure, whether = >>> this is intended. >> >> Feel free to improve... > > Surely if you pass it an odd size you made a mistake - either the wrong function was used or you computed the size incorrectly. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r233052 - head/share/mk
On 21/03/2012, at 8:10, Chris Rees wrote: > Yes-- it'd be nice if less could read the ex:ts=4 bit. > > That can go on my todo list. Are you going to teach it emacs commands for the same? ;) IMO any file which wants to be viewed with tabs != 8 spaces is broken. The extra cost of disk to store 4 spaces for your odd number of indent lines is trivial.. I understand that bsd.port.mk and friends have legacy and that is fine but I don't think it's a good precedent to use when indenting other makefiles (which is a great idea IMO) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r233052 - head/share/mk
On 21/03/2012, at 11:18, Mark Linimon wrote: > Personally, I'd like to see us pick a "recommended way for new code", > whether it's one or two spaces, whatever. (8 spaces seems too much.) 2 space indents are fine IMO, but they are spaces. A tab character should be viewed as 8 spaces wide, but that doesn't force you to have 8 space wide indents. If you change tab width then you need to teach each editor and viewer that could possibly read your file what that width is, which is basically an impossible task. Yes using just spaces, or coalescing 8 spaces into a tab uses more disk space than just tabs, but that amounts to sweet FA these days. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r247359 - head/sbin/reboot
On 28/02/2013, at 3:08, John Baldwin wrote: >> URL: http://svnweb.freebsd.org/changeset/base/247359 >> >> Log: >> Clarify that overriding the -h/-D flags through flags in device.hints >> only works for sio(4) but not for uart(4) which no longer has this flag. > > You should probably just remove the flag entirely. sio(4) doesn't build on > 8.x and later. The handbook will need fixing too since it mentions sio(4) and -D/-h. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
