Re: Dropping support for old binaries
Hello, Brian Buhrow writes: > hello. There is a proposal around to drop support for old NetBSD > binaries in current ersions of NetBSD. For example, nuking COMPAT_NOMID, > COMPAT_10, COMPAT_12, COMPAT_13 COMPAT_14, etc. from the the -current > source tree. I'll let the original poster post his reasons for this > proposal on this list, but here's my response to that proposal: I suggest that you don't misrepresent the original proposal. The original proposal was about dropping the support from GENERIC, that is not exposing rotten code to potential attackers. Those who want to continue running old code can always either load a module or build custom kernel. This is actually good since this could somewhat improve the image of NetBSD in some information security circles. -- HE CE3OH...
Re: Removing ARCNET stuffs
mlel...@serpens.de (Michael van Elst) writes: > jo...@britannica.bec.de (Joerg Sonnenberger) writes: > >>On Tue, Jun 02, 2015 at 11:47:01AM -0700, Dennis Ferguson wrote: >>> Asking for ARCNET support in the absence of hardware to test on, >>> however, is really asking for something quite different. Since you >>> can't make more than small, mechanical changes to anything and expect >>> it to work without testing (and I'm not even sure about the small, >>> mechanical changes) what is being asked instead is that nothing be >>> done that requires changes to the ARCNET code on the disk right >>> now, nor the framework it relies on to operate, while making it >>> someone else's problem to figure out how to deal with that constraint. >>> This isn't fair, and I don't think it has any possibility of working. > >>Amen. > > There are several NetBSD developers that own ARCNET hardware and > that could help out. You could also get new cards, at "industry" prices. This tricky "could!" It almost never answers the question, whether it is some hypothetical possibility or readiness to act. -- HE CE3OH...
Re: Groff
tlaro...@polynum.com writes: > On Thu, Jun 04, 2015 at 08:05:16AM +0300, Aleksej Saushev wrote: >> tlaro...@polynum.com writes: >> >>> [pledge for TeX---not TexLive] >> >> There's a lot better approach that beats all the above on all accounts. >> >> Import libxml2, libxslt, w3m that are all readily available, convert man >> pages to a human-readable and human-writable format, which is XML, >> and stop using archaic formats. >> >> This has a number of significant benefits over TeX or roff: >> 1. XML is well-known, the syntax doesn't require anything special to learn. >> 2. There's abundancy of software to process it. >> 3. XML can be used immediately, without preprocessing step (just point >> web browser at it, and it will load stylesheet and perform XSL >> transformation for you). >> 4. Desktop users will have really good rendering as provided by Firefox >> or Webkit. > > That there may be not software but bloatware: Firefox and al. to > succeed, more or less, to provide a rendering has nothing to appeal to > me. That this bloat format has to be processed by tools that depend on > gigabytes of software needing C++ compiler and al. to ---try to--- be > compiled is definitively not what I call a "system" typesetting. Needing > gigs of memory to try to run firefox or chrome or whatever has nothing > to appeal to me; not to mention that the last time I gave a try to > compile chromium it retrieved half of the Google cache as dependencies, > took hours of compilation (on a rather decent computer) to finally fail > to _link_ the objects because 4 gigs of memory was not enough! I suggest that you stop talking nonsense. It negatively affects NetBSD's image. Processing XML does not require more resources than processing runoff. Writing full-blown XML parser is a task for a student lab (if you throw internal DTD support off, XML grammar is only marginally more complex than that of, say, JSON). If you don't like XSLT, writing tree walker is definitely not a rocket science. Besides, $ pkg_info -S libxslt Information for libxslt-1.1.28nb3: Size in bytes including required pkgs: 15548744 and you can strip it down further, if you care. Not to mention that Firefox is not the only typesetting engine out there. Fanatics of curses-based solution can use more primitive ones. > Furthermore, all the text tools provided by the system (and even only > the POSIX.2 text tools) can be readily used on a TeX file. > > Finally, my idea would be the reverse: use the lean TeX engine TeX is definitely more heavyweight solution than full-blown XML processing stack. -- HE CE3OH...
Re: Groff
Johnny Billquist writes: > On 2015-06-04 09:43, Matt Thomas wrote: >> >>> On Jun 3, 2015, at 10:05 PM, Aleksej Saushev wrote: >>> >>> Just in case you don't know, nearly any user has libxml2 and libxslt >>> installed anyway. >> >> None of my systems do. > > I thought Aleksej was joking... The suggestion to get rid of > groff because it needed C++, and replace it with XML, a full > blown web browser, and god know how many libraries seemed like > the ultimate joke. Have you ever tried checking what you use in an argument? Obviously, not. I don't see another sensible explanation to this lie. It is definitely not hard to issue two(!) commands to check it: $ pkg_info -n libxml2 Information for libxml2-2.9.2nb2: Requires: xmlcatmgr>=2.0beta1 $ pkg_info -n xmlcatmgr Information for xmlcatmgr-2.2nb1: Same applies to web browser. This is not 1995, there's a number of different web browsers out there. Some of them are pretty minimal. For instance, Lynx can be built with dependencies only on curses, gettext, openssl and zlib. -- HE CE3OH...
Re: Groff
Matt Thomas writes: >> On Jun 3, 2015, at 10:05 PM, Aleksej Saushev wrote: >> >> Just in case you don't know, nearly any user has libxml2 and libxslt >> installed anyway. > > None of my systems do. I'm sorry, but this is not your virtue. Basically, it tells everyone that you're using NetBSD as an embedded system rather than universal one. It is good that you have found a niche where you can use NetBSD, yet it casts a doubt that NetBSD is any good anywhere. The command below demonstrates that either you're not using NetBSD on your desktop, that is your destop OS is Linux, MacOS or MS Windows, or you're excluded from communication to the rest of society. $ pkg_info libxml2 Information for libxml2-2.9.2nb2: Comment: XML parser library from the GNOME project Requires: xmlcatmgr>=2.0beta1 Required by: shared-mime-info-1.4 policykit-0.9nb16 gstreamer0.10-0.10.36nb7 GConf-2.32.4nb9 libabw-0.1.1nb1 libe-book-0.1.2nb2 libetonyek-0.1.1nb3 libvisio-0.1.1nb4 libgsf-1.14.30 php-5.4.40 libcroco-0.6.8 librsvg-2.40.9nb1 m17n-lib-1.7.0 libbonobo-2.32.0nb9 libglade-2.6.4nb22 gnome-vfs-2.24.4nb27 libbonoboui-2.24.4nb25 libsoup24-2.48.1nb1 liblangtag-0.5.6 ImageMagick-6.9.1.1 libxslt-1.1.28nb3 dia-0.97.2nb23 libwmf-0.2.8.4nb15 inkscape-0.91nb3 netpbm-10.68.02nb1 clang-3.6.0nb1 libgdata-0.6.6nb16 evolution-data-server-2.32.3nb35 libgnomeprint-2.18.8nb22 gtksourceview-1.8.5nb30 gtksourceview2-2.10.5nb23 pspp-0.6.2nb27 gst-plugins1-base-1.4.5 libcmis-0.5.0nb1 raptor2-2.0.15 rasqal-0.9.33 libreoffice4-4.4.2.2nb4 py27-libxml2-2.9.2 Description: XML parser library from the GNOME project Homepage: http://xmlsoft.org/ -- HE CE3OH...
Re: Groff
tlaro...@polynum.com writes: > On Mon, Jun 01, 2015 at 05:50:07PM +, David Holland wrote: >> On Sun, May 31, 2015 at 09:24:48PM -0400, Andrew Cagney wrote: >> >> > (oh and please delete C++ groff, just replace it with that AWK script) >> >> which awk script? :-) >> >> (quite seriously, I've been looking for a while for an alternative to >> groff for typesetting the miscellaneous articles in base. >> > > (Delenda Carthago...) Once more, I will re-advertise that the complete > Donald E. Knuth typesetting system is available, that can be even > restricted to strictly just D.E.K.'s work (even with the fonts, > this is a matter of far less than 10 MB); that is pure C89 > (some auxiliaries invoke POSIX.2 utilities, mainly sh(1) but these > are just auxiliaries); that comes with the fonts, the ability to > design the fonts, the formatting (TeX) and a format dvi à la PDF > that can be used to generate a formatted text version; the means > to use also mathematics; the means to draw figures rasterized with > METAFONT (more general figures with MetaPOST, supplementary, but > this generates PS); and with a compiling framework that is not GPLn > but BSD. > > Since for a system written in C the main "human" language is "CEE" > that is a kind of technical english, the limitation to 8 bits (that > could be changed by dealing with font directories and not font > files, i.e. a directory of 256 glyphes sub-font) is not an immediate > problem. > > The conversion from roff to tex should be easier than the > reverse and I expect relatively simple for 95% of the work (the man > pages). > > IMHO, the main tasks remaining are (could be GSoC by the way): > - give a DVI viewer (starting from scratch); > - extend with the minimal changes TeX to be able to use UTF-8 (meaning, > as UTF-8, that ASCII can be fed as is, but that this is just 8 bits > still at entry---mouth); > - whether develop a C SmallScript to be able to interpret the limited > MetaPOST PostScript; or extend DVI and METAFONT to handle MetaPOST > capabilities and rasterize the figures, in order for the system to > be totally self-sufficient (no PDF viewer or PostScript interpreter to > be able to render the pages). > > It is here: > > http://www.kergis.com/en/kertex.html > > It is not orphaned but stalled for the moment due to ETIME. There's a lot better approach that beats all the above on all accounts. Import libxml2, libxslt, w3m that are all readily available, convert man pages to a human-readable and human-writable format, which is XML, and stop using archaic formats. This has a number of significant benefits over TeX or roff: 1. XML is well-known, the syntax doesn't require anything special to learn. 2. There's abundancy of software to process it. 3. XML can be used immediately, without preprocessing step (just point web browser at it, and it will load stylesheet and perform XSL transformation for you). 4. Desktop users will have really good rendering as provided by Firefox or Webkit. 5. You can have better searching and indexing tools (because they exist already). 6. You can enforce all those rules that are currently enforced manually by wizd(8) with an already existing Schema definition. Just in case you don't know, nearly any user has libxml2 and libxslt installed anyway. -- HE CE3OH...
Processes get stuck in layerfs in NetBSD 6.99.28 i386
Hello, After updating to current I have problem that some processes get stuck on layerfs wchan. suggested that it may be have been fixed recently, but after updating kernel to the source as of around 2013-12-06 05:00:05 MSK I still have the problem: $ ps -axo pid,wchan,command | awk '$2 == "layerfs"' 294 layerfs /usr/bin/find /mnt/packages -type l -name xkbcomp-1.2.4.tgz -prin This is part of serial (no MAKE_JOBS, not parallelised) bulk build, the process runs in chroot environment and the configuration of file systems is this: /dev/wd0a on / type ffs (log, local) kernfs on /kern type kernfs (local) ptyfs on /dev/pts type ptyfs (local) procfs on /proc type procfs (local) tmpfs on /tmp type tmpfs (local) /usr/jail/pbulk-data/mnt on /usr/jail/pbulk/mnt type null (local) ptyfs on /usr/jail/pbulk/dev/pts type ptyfs (local) -- HE CE3OH...
Re: Why do we need lua in-tree again? Yet another call for actual evidence, please. (was Re: Moving Lua source codes)
Hello, Lourival Vieira Neto writes: > On Fri, Oct 18, 2013 at 9:08 AM, Taylor R Campbell > wrote: >>Date: Thu, 17 Oct 2013 19:16:16 -0300 >>From: Lourival Vieira Neto >> >>Lua is a tool, not an end in itself. I think that you are formulating >>a chicken-and-egg problem: we need the basic support for then having >>applications, and we need applications for then having basic support. >> >> This is not a chicken-and-egg problem. You can make an experimental >> kernel with Lua support and make an experimental application in Lua, >> all before anything has to be committed to HEAD[*]. Then you can show >> that the application serves a useful function, has compelling benefits >> over writing it in C, and can offer confidence in robustness. >> >> [*] You could do this in a branch, you could do this in a private Git >> repository, or you could even just do this in a local CVS checkout >> (since kernel Lua requires no invasive changes, right?). > > Yes, but how do we do device driver development? We are branching the > tree for each non-intrusive and disabled-by-default device driver? If > we have developed a device driver for an uncommon device, we have to > put it in a branch? (Please, note I'm friendly asking that). We didn't import yet another programming language interpreter for driver development previously. Besides, what are drivers developed in Lua so far? If I understand it correctly, the only driver is the Lua interpreter itself. >>That is not about needing, but it is about supporting a certain >>kind of agile development, prototyping, customization and >>experimentation in the NetBSD kernel (how could it be hurtful?). >> >> Prototyping and experimentation is great! Show examples! What hurts >> is getting bitrotten code that nobody actually maintains or uses (when >> was the last Lua update in src?) and provides a new Turing machine >> with device access in the kernel for attack vectors. > > I don't see how an optional module could be used for attacks. If users > enable that, they should know what they are doing (such as loading a > kernel module). Was anything done to warn users? >>[1] https://github.com/dergraf/PacketScript >>[2] http://www.pdsw.org/pdsw12/papers/grawinkle-pdsw12.pdf >> >> In the two links you gave, I found precisely five lines of Lua code, >> buried in the paper, and those five lines seemed to exist only for the >> purpose of measuring how much overhead Lua adds to the existing pNFS >> code or something. > > I'm just showing examples of how it could be useful for user > applications. I understand that you do not agree with that. But I'm > not arguing that we have to add these applications into the tree. I'm > arguing that we could benefit users with such a tool. The problem is that the number of such users is negligible and all of them are developers that are able to build their kernel module outside the tree. -- BCE HA MOPE!
Re: Why do we need lua in-tree again? Yet another call for actual evidence, please. (was Re: Moving Lua source codes)
Hello, Lourival Vieira Neto writes: > On Fri, Oct 18, 2013 at 1:31 PM, Aleksej Saushev wrote: >> (...) >>> Lua is a tool, not an end in itself. I think that you are formulating >>> a chicken-and-egg problem: we need the basic support for then having >>> applications, and we need applications for then having basic support. >> >> The problem with your approach is that such "chicken-and-egg" problems >> are to be solved _at_once_ rather than laying "eggs" everywhere around >> and have everyone else wait till at least one "chicken" appears. > > No. I'm talking about put just one egg, just a device driver. Sorry, but this is not "just one egg". "And counting" was your reaction to complaints that almost all the code related to Lua is the code to support Lua itself rather than anything else. >>> Sure, we do not *need* a script language interpreter embedded in the >>> kernel, as we do not need a specific file system. But I do not get why >>> we should not. There is current development of applications being done >>> right now. Also, there is a few interesting works that used Lunatik in >>> Linux [1, 2] that could be done more easily now in NetBSD just because >>> we have the right environment for that. That is not about needing, but >>> it is about supporting a certain kind of agile development, >>> prototyping, customization and experimentation in the NetBSD kernel >>> (how could it be hurtful?). I think that is why we *should* (not need) >>> have this on the tree. IMHO. >> >> I have to point out that "interesting work" is commonly used as a sort of >> euphemism to refer to highly experimental work with unclear future. > > Yes. But I'm talking about "interesting *user* work". I'm not claiming > that they should be in the kernel. I'm just saying that, IMHO, we > should incorporate a small device driver that facilitates this kind of > development (outside the tree). I'm of opinion that this device driver can and should stay outside the tree until its utility can be demonstrated without this much strain. At last this is one of the reasons why we support kernel modules. >> You tell that there's "interesting work" using Lua in Linux. >> Was it accepted in any experimental Linux distribution like Fedora? >> What was the outcome of discussion among linux kernel developers? >> Currently there's no indication that it was accepted anywhere. > > Really don't know. I'm not a member of these communities neither I'm > claiming to incorporate such works here. However, I think that there > was a discussion about PacketScript on OpenWRT, but I don't know how > it evolved. This demonstrates that Lua isn't actually useful in the kernel. >> I doubt very much that we want such unreliable development practices >> like "agile" ones in the kernel, and experimentation work can be done >> easier and better in a branch or a personal repository. > > I agree with you in this point: experimental work should be done aside > from the tree. > >> And last. The appeal to "why not" is defective. NetBSD is not your >> personal playground, there exist other people who have to deal with >> the inadvertent mess you can leave after you. That's why you ought >> to present solid arguments that justify why other people should tolerate >> your experimentations. > > I guess you misunderstood that. I'm not arguing that we should do it > just because there is no contrary argument. I sincerely asked 'why > not?' trying to understand the contrary argumentation. Also, I'm not > saying that you should tolerate my experimentation. Far away from > that. I haven't committed anything nor tried to impose nothing. On my side it sounded like that, sorry, if I'm wrong. > I'm > just trying to make a point of view and understand yours. When I > talked about experimentation, I was trying to say that providing > support for that kind of experimentation for users sounds a good idea > for me and I don't see how it is prejudicial. Which doesn't mean that > I'm proposing that my personal experimentation should be in tree. The problem as I see it is that we have one developer (two at most) pushing hard for Lua in base and in kernel and providing no satisfactory arguments why this is to be done at all. Lack of any real code for years reinforces such doubts. "Why not" sounds as an argument for highly experimental work in this context. And I wouldn't have anything against this "why not" if all the work were dressed accordingly. For now I'd say that Lua support hasn't demonstrated any benefit. I'd say that it should be removed and the work continued in a branch until benefits become more clear. -- BCE HA MOPE!
Re: Why do we need lua in-tree again? Yet another call for actual evidence, please. (was Re: Moving Lua source codes)
Hello,
Lourival Vieira Neto writes:
> On Thu, Oct 17, 2013 at 1:26 PM, Jeff Rizzo wrote:
>> On 10/14/13 1:46 PM, Marc Balmer wrote:
>>>
>>> There is real word, real working code. In userland and in kernel space.
>>> There are developers waiting for the kernel parts to be committet, so
>>> they can continue their work as well.
>>
>> *Where* is this code? The pattern I see happening over and over again is:
>>
>> NetBSD Community: "Please show us the real working code that needs this"
>>
>> mbalmer: "the code is there!" (pointer to actual code not in evidence)
>>
>> I do not doubt that something exists, but the onus is on the person
>> proposing the import to convince the skeptics, or at least to make an actual
>> effort. I see lots of handwaving, and little actual code. YEARS after the
>> import of lua into the main tree, I see very little in-tree evidence of its
>> use.
>>
>> In fact, what I see is limited to :
>>
>> 1) evidence of lua bindings for netpgp.
>> 2) evidence of some tests in external/bsd/lutok
>> 3) the actual lua arc in external/mit/lua
>> 4) gpio and sqlite stuff in liblua
>> 5) some lua bindings in libexec/httpd ("bozohttpd")
>> 6) two example files in share/examples/lua
>> 7) the luactl/lua module/lua(4) stuff you imported yesterday
>
> ...and counting. There is also ongoing working happening =).
As Jeff points what is counting is support code.
>> Am I missing something major here? The only actual usage I see is netpgp
>> and httpd; the rest is all in support of lua itself. I do not see evidence
>> that anyone is actually using lua in such a way that requires it in-tree.
>> When you originally proposed importing lua back in 2010, you talked a lot
>> about how uses would materialize. It's now been 3 years, and I just don't
>> see them. If I am wrong about this, I would love some solid pointers to
>> evidence of my wrongness.
>>
>> Now you're using very similar arguments for bringing lua into the kernel; I
>> would very much like to see some real, practical, *useful* code
>> demonstrating just why this is a good thing. Beyond the 'gee, whiz' factor,
>> I just don't see it.
>
> Lua is a tool, not an end in itself. I think that you are formulating
> a chicken-and-egg problem: we need the basic support for then having
> applications, and we need applications for then having basic support.
The problem with your approach is that such "chicken-and-egg" problems
are to be solved _at_once_ rather than laying "eggs" everywhere around
and have everyone else wait till at least one "chicken" appears.
> Sure, we do not *need* a script language interpreter embedded in the
> kernel, as we do not need a specific file system. But I do not get why
> we should not. There is current development of applications being done
> right now. Also, there is a few interesting works that used Lunatik in
> Linux [1, 2] that could be done more easily now in NetBSD just because
> we have the right environment for that. That is not about needing, but
> it is about supporting a certain kind of agile development,
> prototyping, customization and experimentation in the NetBSD kernel
> (how could it be hurtful?). I think that is why we *should* (not need)
> have this on the tree. IMHO.
I have to point out that "interesting work" is commonly used as a sort of
euphemism to refer to highly experimental work with unclear future.
You tell that there's "interesting work" using Lua in Linux.
Was it accepted in any experimental Linux distribution like Fedora?
What was the outcome of discussion among linux kernel developers?
Currently there's no indication that it was accepted anywhere.
I doubt very much that we want such unreliable development practices
like "agile" ones in the kernel, and experimentation work can be done
easier and better in a branch or a personal repository.
And last. The appeal to "why not" is defective. NetBSD is not your
personal playground, there exist other people who have to deal with
the inadvertent mess you can leave after you. That's why you ought
to present solid arguments that justify why other people should tolerate
your experimentations.
--
BCE HA MOPE!
Re: Lua in-kernel (lbuf library)
Marc Balmer writes: > Am 15.10.13 23:01, schrieb Lourival Vieira Neto: > >>> Also, having to switch mentally between zero-based arrays in the kernel C >>> code and 1-based arrays in the Lua code make my head ache. >> >> It's something that doesn't bug me so much.. But, if necessary it >> could be changed to 0-based in this userdata. > > In C an array index is actually an offset from the top, so 0 is the > natural way to denote element nr. 1 in C. In Lua, a numeric array index > is not an offset, but the ordinal array position. So 1 is the natural > way to denote the first element. > > Strictly speaking, it's actually C that is weird: Index n denotes array > element n + 1... This depends on your background. If you studied or dealt with mathematical logic, set theory, or foundations of mathematics, then you start counting natural numbers (ordinals) from 0. In this respect C is more logical (pun intended) than Lua. > Following the principle of least astonishment, I would not recommend > starting to do 0 based stuff in Lua, a Lua programmer certainly expects > things to start at 1. It is hard to tell what is the least astonishing here. You propose Lua as a language embedded into C rather than separate one. I'd say that Lua designers made wrong decision here. -- BCE HA MOPE!
Re: Sending ATA commands?
Matt Thomas writes: > On Aug 11, 2013, at 9:37 PM, Mouse wrote: > >>> [...], I wonder if you could attach the HPA area as an additional >>> partition on the default disklabel, or, if the disk is gpt >>> partitioned, fake up another partition in the gpt table. >> >> I don't see any reason why not. I'm not sure whether you're proposing >> that the HPA not be accessible any other way or whether this is just a >> default. > > or make it a ld device attached to the wd device. Out of curiousity, how does it differ from dk(4)? -- BCE HA MOPE!
Re: uname (3), and uname (1) values, 6.0_[A-Z]* and building userland projects
jtow...@soncom.com (John R. Towler) writes:
> Hello,
> The topic is uname(1) and uname (3), sysctl -a entries and their
> intended semantics in the English words of the man pages.
>
> I have a problem with the current (110.75) and last versions
> (110.74) of smlnj, of which I thought to build the newest
> smlnj-110.75 this morning.
SML/NJ has awful build system.
> My question is that for other programs that rely on uname(1) and
> uname(3) and the assigned readings in the man pages, is what the man
> pages mean reflected in kern.version = {above version with ident stuff}
> above and uname -a = same {above version with ident stuff and uname -m},
"Other programs" shouldn't rely on uname in general.
> I can work with the smlnj build system to work around this build
> problem. But it seems that there should be a uname (1) option which
> selects just the major or major.minor version of the OS, and this
> problem area in where and how the kern.version information in the
> /usr/src build also for uname -a gets fed to the libc functions etc.
>
> Maybe this is the POSIX spec also which is cited. I can do more reading
> about this. But people know here, why is uname -v under the current
> reading and implementation the OS name etc. and then the kernel config
> ident string and compilation information, and where the problem is for
> my concern --- how does a calling program branching on OS features, make
> use of the full OS name number and ident tags here for uname -v? How
> would a user or other program know from the kernel compilation version
> details anything about what to expect in terms of system services and
> characteristics of the OS? I know because I configured the kernel to
> build it or used a given one. It helps me, as admin of the system to
> remember what was done, but that is all. So what systematic solutions
> or understandings will help me address this problem area for using
> uname(1) or uname(3) with other programs.
>
> For smlnj-110.[4-7][45] config/{install.sh,_arch_op-n-sys} as
> distributed, I should be able to change the uname -r call in the complex
> of shell scripts which run over the network to fetch as well to just
> select the numeric major version or numeric major.minor versions that
> the build system wants in order to just work. It is possible to chop
> the appended string off with perl or awk or sed and play with the #!
> shell/interpreter etc. and sort out how the numerous shell scripts of
> the build system interact, but none of these are as simple and elegant.
> So, I thought I would ask people who know how this came about in the
> build of /usr/src and the kernel and what best reflects the systematic
> design of NetBSD and (BSD) Un*x and Unix.
You have better chances starting with lang/smlnj and updating it.
--
HE CE3OH...
Re: Lost file-system story
James Chacon writes: > On Tue, Dec 13, 2011 at 4:09 PM, Greg A. Woods wrote: >> At Wed, 14 Dec 2011 09:06:23 +1030, Brett Lymn >> wrote: >> Subject: Re: Lost file-system story >>> >>> On Tue, Dec 13, 2011 at 01:38:57PM +0100, Joerg Sonnenberger wrote: >>> > >>> > fsck is supposed to handle *all* corruptions to the file system that can >>> > occur as part of normal file system operation in the kernel. It is doing >>> > best effort for others. It's a bug if it doesn't do the former and a >>> > potential missing feature for the latter. >>> >>> There are a lot of slips twixt cup and lip. If you are really unlucky >>> you can get an outage at just the wrong time that will cause the >>> filesystem to be hosed so badly that fsck cannot recover it. Sure, fsck >>> can run to completion but all you have is most of your FS in lost+found >>> which you have to be really really desperate to sort through. I have >>> been working with UNIX for over 20years now and I have only seen this >>> happen once and it was with a commercial UNIX. >> >> I've seen that happen more than once unfortunately. SunOS-4 once I think. >> >> I agree 100% with Joerg here though. >> >> I'm pretty sure at least some of the times I've seen fsck do more damage >> than good it was due to a kernel bug or more breaking assumptions about >> ordered operations. >> >> There have of course also been some pretty serious bugs in various fsck >> implementations across the years and vendors. > > I'd be suspicious of fsck failing on a regularly mounted disk with > corruption that can't otherwise be tracked to outside influences (bad > ram, bad disk cache, etc). I've seen some bizarre things happen on ram > errors over the years for instance. I've got infinite sequence of nested subdirectories on new hardware and "stable" FreeBSD 5.3 once. Something like http://xkcd.com/981/ fsck refused to work there. -- HE CE3OH...
Re: Lost file-system story
Donald Allen writes: > On Sat, Dec 10, 2011 at 1:14 PM, Edgar Fuß wrote: >> Of course, keeping the on-disc metadata in a ``repairable'' state incurs a >> performance penalty. >> >> So you seem to be asking for the File System Holy Grail: a file >> system that is as fast as asyncronous metadata writes, yet able to >> survive any possible kind of unclean shutdown. Such a thing, to my >> knowledge, doesn't exist. > > I'm sorry, I don't wish to be rude, but you, too, seem not to have > read what I've written carefully. Or, perhaps the fault is mine, that > I simply haven't made myself sufficiently clear. I've talked at length > about the behavior of Linux ext2 and that it was more than acceptable, > both from a standpoint of performance and reliability. I am not > looking for something "able to survive any possible kind of unclean > shutdown". I'm looking for a reasonably low joint probability of a > crash occurring *and* losing an async-mounted filesystem as a result. > I simply want an async implementation where the benefit (performance) > is not out-weighed by the risk (lost filesystems) and I cited Linux > ext2 is an example of that. If that's not clear to you, then I'm > afraid I can't do better. I think that it should be clear that async mount excludes what you want. Async mount basically means that you create fresh file system after boot. In linux it may mean another thing (e.g., it may be less asynchronous), in BSDs it means exactly that. Thus, unless you really can afford starting file system from scratch, don't mount it async. -- HE CE3OH...
Re: emap
Hello! y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: >> Thor Lancelot Simon writes: >> >>> On Fri, Nov 25, 2011 at 12:50:58PM +0400, Aleksej Saushev wrote: >>>> Mindaugas Rasiukevicius writes: >>>> >>>> > y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: >>>> >> hi, >>>> >> >>>> >> what's the status of emap and pipe? >>>> >> >>>> > >>>> > ... and encourage our users to use amd64 instead >>>> > of i386. >>>> >>>> I'm sorry to intervene, what about WINE? Unless we're going to have it >>>> functional on amd64, encouraging is useless. >>> >>> I don't understand your comment. Are you suggesting that a large fraction >>> of >>> NetBSD/i386 users use WINE and therefore would not be able to switch to the >>> amd64 port? >> >> I mean that those users who could switch most probably have switched already. >> And one of serious reasons to stay on i386 is functional WINE. > > as we now have non-stack-based pthread_self (thanks joerg), porting > the recent versions of wine should not be too hard. does it help wine > on amd64? Thanks for the information, I'll try to check (though I need to get current amd64 setup first). -- HE CE3OH...
Re: emap
Thor Lancelot Simon writes: > On Fri, Nov 25, 2011 at 12:50:58PM +0400, Aleksej Saushev wrote: >> Mindaugas Rasiukevicius writes: >> >> > y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: >> >> hi, >> >> >> >> what's the status of emap and pipe? >> >> >> > >> > ... and encourage our users to use amd64 instead >> > of i386. >> >> I'm sorry to intervene, what about WINE? Unless we're going to have it >> functional on amd64, encouraging is useless. > > I don't understand your comment. Are you suggesting that a large fraction of > NetBSD/i386 users use WINE and therefore would not be able to switch to the > amd64 port? I mean that those users who could switch most probably have switched already. And one of serious reasons to stay on i386 is functional WINE. -- HE CE3OH...
Re: emap
Mindaugas Rasiukevicius writes: > y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: >> hi, >> >> what's the status of emap and pipe? >> > > ... and encourage our users to use amd64 instead > of i386. I'm sorry to intervene, what about WINE? Unless we're going to have it functional on amd64, encouraging is useless. -- HE CE3OH...
Re: add DIAGNOSTIC back to GENERIC/INSTALL
Mindaugas Rasiukevicius writes: > - DDB_ONPANIC=1 and DDB_COMMANDONENTER="bt;show regsisters" and perhaps > also "call ddb_vgapost" in the beginning (not sure if there are any > potential side effects?). Otherwise, not getting information from DDB > is just counter-productive, plus we get not very useful reports, when > backtrace is missing. I'd say that at least "call ddb_vgapost" should enter default sysctl.conf, at least commented out. It isn't trivial to learn that the functionality exists, and it is the only way to get to debugger on modern machines without serial interface. -- HE CE3OH...
Re: Kernel modules in non-default directories
Mark Weinem writes: > On Tuesday 16 March 2010 20:51:23 Alan Barrett wrote: > >> On Mon, 15 Mar 2010, Aleksej Saushev wrote: >> > [how to boot] NetBSD so that it looks for modules in non-default >> > directory? >> >> You can't [...] > > Is this problem specific to NetBSD? Do other operating systems provide > solutions? Yes, FreeBSD allows selecting directory where kernel and modules reside. -- HE CE3OH...
Re: Unsafe GENERIC? - Re: (unknown)
Paul Goyette writes: > On Tue, 16 Mar 2010, Aleksej Saushev wrote: > >> Well... Could we arrange it so that we have safe monolithic GENERIC >> until issues are resolved somehow? > > For i386, use MONOLITHIC instad of GENERIC > > For amd64, the default is still MONOLITHIC, if I remember correctly. This produces unnecessary confusion and nothing more. Update procedure becomes more machine-dependent. Even on commodity hardware, where some users prefer to stay with i386 because of e.g. WINE and other 32-bit only software. -- HE CE3OH... pgpWIWokP0FMi.pgp Description: PGP signature
Unsafe GENERIC? - Re: (unknown)
Alan Barrett writes: > On Mon, 15 Mar 2010, Aleksej Saushev wrote: >> While here, can anyone enlighten us how one boots NetBSD so that it looks >> for modules in non-default directory? > > You can't, and the people who want NetBSD to move to modular kernels > don't seem to care. Until this problem is fixed, I will try to avoid > using modular kernels. Well... Could we arrange it so that we have safe monolithic GENERIC until issues are resolved somehow? It isn't nice to provide highly experimental feature as default one. Until release management is arranged so that drivers are backported faster, users of commodity hardware are forced to use current sometimes. -- HE CE3OH...
Re: (Semi-random) thoughts on device tree structure and devfs
Johnny Billquist writes: > I seem to remember that way back there was even a tool (in > pkgsrc?) which extracted your current device setup, and created > a config file from that, so that you would always get the same > enumeration, no matter what else showed up on the machine. > > The point is, the config file totally, and exactly describes > your hardware setup. It takes only a minute to move the very same external HDD from one bus to another one, you only need to pull FireWire connector off and connect with USB cable. No screws involved. -- HE CE3OH...
