Re: [osol-discuss] zfs and export/home
You should be posting to zfs-discuss for ZFS-specific questions. Perhaps you are confused about the difference between 'used' and 'referenced'? For example, consider this output from my desktop: NAME USED AVAIL REFER MOUNTPOINT pool/local/builds 696M 680G 32.2K /builds pool/local/builds/fixes296M 680G 296M /builds/fixes pool/local/builds/work 400M 680G 400M /builds/work Notice that 'used' is the sum of the two filesystems underneath it. But '/builds' itself is also a filesystem, and so the amount of space referenced by that particular filesystem is quite small (because it isn't actually mounted, it has basically no data). Quotas are *not* inherited. Setting a quota on 'pool/local/builds' will apply to the total (used) space of itself all child filesystems and snapshots. - Eric I'm having trouble understanding this: zfs create zfspool/home zfs create zfspool/home/u1 zfs create zfspool/home/u2 For arguments sake u1 contains 5gb worth of data and u2 7gb worth of data. Doing 'zfs list' zfspopol/home/u1 and zfspool/home/u2 shows 5gb and 7gb respectively. However zfspool/home only shows a couple of kb, not my expected 12gb. What is the thought behind separate filesystems and inheritance?! Using 'zfs set quota=10G zfspool/home' is inherited to underlying filesystems, but not the accumulated total usage is being considered. Am I thinking of this in the wrong way, or...? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Sparc Dissassembler
I have a prototype sparc disassembler I've put together available at http://www.madhack.com/~jason/dis_sparc.c There are still some things left to do (mostly implement support for most of the standard synthetic instructions), plus whatever shows up during testing. Unfortunately, I don't have access to Sparc machines outside of work, so sort of starting to manually assemble sparc instructions and feed them to the code, I have no way of testing the code, so I'm hoping to solicit some assistance with testing and validation. Any takers? I can't seem to access the above site, but a good start for testing would be to iterate over all possible instructions and compare the output with the existing libdisasm. When I was finishing up the amd64 disassembler work, I did a similar thing with the GNU disassembler, though the fundamental output differences meant it would never work perfectly. The SPARC version should be significantly easier since you don't have to deal with variable-length instructions, and you're doing an apples-to-apples comparison. One additional hack I made was to detect when I was dealing with an immediate value, and then skip any remaining iterations, to cut down on the number of different instructions to test. The assumption was that 'movq 0x0, %rax' would be the same as 'movq 0x1, %rax' for all possible constants. Also, make sure you test all varieties of DIS_SPARC_* disassembler flags (v8, v9, etc). After that is working, you should be able to verify that dis(1) produces the same output for all of /usr/bin/* and /usr/lib/*. You'll then want to verify that '::dis' produces the same output in mdb(1) for a random selection of functions in running programs and the kernel. And check kmdb(1M), though if mdb is working it's pretty hard to break kmdb. If you get all of the above working, then there's not much that running on different machines will give you, though running the object tests for both sun4u and sun4v machines would be a useful test. Let me know if you need any additional help once you get to this point, - Eric This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Having to subscribe to post considered obnoxious (Re: [zfs-discuss] OSOL mailing list issues)
On Fri, May 12, 2006 at 03:32:43PM -0500, Nicolas Williams wrote: Also, I'm getting tired of replying to some e-mail only to get a post awaits moderator approval reply. I understand why we do that for non-subscribers. And I guess we wouldn't want to by default treat @sun.com posters as permitted to post w/o moderation. The ZFS discuss list was getting heavily spammed, resulting in me having to spend the first 15 minutes of every day sifting through notifications and going to reject the messages. The current policy for zfs-discuss is to reject any non-member mail, though all *.sun.com addresses are automatically accepted. What we really need is something like if you have an opensolaris.org account or if you are subscribed to _any_ opensolaris list, but mailman doesn't seem to integrate well with other systems. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [zfs-discuss] Re: [osol-discuss] However, the zfs file system /export/zfs_0 must be shared ?? What ?
On Mon, Apr 17, 2006 at 09:41:21PM +0200, Holger Berger wrote: It is still a bug which should be fixed. The requirement that only the base of a ZFS file system can be shared is a serious limitation which will hamper or even prevent deployment of ZFS at large sites. I haven't quite grokked the original thread completely, but the above statement isn't true. You can _always_ use /etc/dfs/dfstab to share whatever directories you want. The zfs set sharenfs=XXX syntax is just a simplified interface for managing shares, and has the beneficial side effect that such options are kept with your data (in the case of import/export, for example). There will always be things you may want to do (such as sharing it under a different name, or sharing subdirectories of a filesystem) which will exceed the capabilities of this simplified interface. Hope that helps, - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: CIFS group creation request.
On Thu, Jan 19, 2006 at 01:54:43PM -0500, Mark Sweeney wrote: Furthermore, these other FS's have communities, so unless we want to send the message out that CIFS will be a second class citizen on Solaris, I think it would be reasonable to match the level of exposure this gets on the site with the level of exposure of these other communities. The other communities were created before projects existed. If you read the ZFS community proposal, you will note this was explicitly called out at the time. It was understood that it may migrate to a project at a future date under the umbrella of a larger storage/filesystem community. This shouldn't be used as justification for future projects to follow this path. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: CIFS group creation request.
On Thu, Jan 19, 2006 at 04:34:57PM -0500, Mark Sweeney wrote: I want to host a community which already exists, the 'CIFS community', on the OpenSolaris website. I want to do this since we have several implementations that work on Solaris of CIFS already and especially since there is a native OpenSolaris client coming out, which has been wanted for some time. Going to google and typing 'CIFS community' as a search will show you some results of where the CIFS community members lurk for other operating systems or for specific cross-platform implementations. If ZFS, and indeed, all the FS's may migrate to being projects in a Filesystems community at some point then that's fine. Until then, I would prefer to keep things consistent and organized, and we can move them all together. A lack of consistency in organization would bother me. I have no qualms about creating a CIFS community, and have no strong opinion on the overall direction of this request. While there may be dozens of other reasons for creating a community over a project, I was only pointing out that the above, specific, rationale is broken and inadequate. Do not use lack of consistency as justification for making the wrong choice. Stephen gave precise criteria for establishing a community versus a project. Don't use existing communities as justification, since by nature they did not have to address these questions at the time they were created. Because ZFS did it or it would be inconsistent with UFS are not valid reasons, nor should the establishment of a Filesystem Community be a prerequesite for making a CIFS project. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 64-bit zfs ?
On Wed, Jan 18, 2006 at 07:16:16PM -0500, Dennis Clarke wrote: I was surprised to not see a sparcv9 in there anywhere. Why? What would the benefit of a 64-bit zfs/zpool binary be? - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: integrating star was: Incorporating open-source
On Sun, Dec 04, 2005 at 02:26:35AM +0100, Joerg Schilling wrote: As mentioned previously, the case has been aproved already in spring... In theory this should have happened before Solaris 10 GA. Unforutnately, the engineer responsible for this particular case (2004/480) has left the company. While Sun searches for available resources, you could speed up the process by submitting the code via request-sponsor, with the appropriate OpenSolaris Makefiles, correct dependencies on OpenSolaris libs, and clean nightly bill of health. Not to mention starting the codereview process. With the case already approved, this would make the job of a Sun sponsor significantly easier. We will continue to search for a motivated engineer with available resources, but any extra help would make the process much faster. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: how to do read/write files in the kernel?
On Wed, Nov 30, 2005 at 05:57:53PM -0800, nice wrote:
I make a kernel module. In the module, I redirect write system call. Before
the data write to the file, I need to handle the data.
In my write system call's function, what I do like this:
1. allocate the memory
2. copy the data from userspace
3. handle the data
4. call the original write system call's function to write the handled data
to the file
...
enc_data = (char *)kmem_alloc(enc_size, KM_SLEEP);
if(!enc_data){
error = ENOMEM;
goto out;
}
memset(enc_data,0,enc_size);
kmem_alloc(..., KM_SLEEP) _cannot_ fail. It will sleep until its
able to get the requested memory. Also, there is kmem_zalloc() to give
you zeroed memory. But why are you zeroing the memory if you're about
to copyin the data?
//copy data from user
if(copyin(cbuf, enc_data, enc_size)){
//free memory
kmem_free(enc_data, enc_size);
error = EFAULT;
goto out;
}
I would check that enc_size is really the correct size (i.e. the length
of 'cbuf'). The copyin() invocation seems correct.
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community Proposal: ZFS
On Fri, Oct 21, 2005 at 07:25:29PM +0200, Joerg Schilling wrote: Will ZFS come with documentation once it is released to Nevada? I am asking this because it would be essential to include man pages in distributions like SchilliX. The plan of record is to have text manpages and a copy of the administration guide available on opensolaris.org once ZFS is released to Nevada. This may change as documentation appears on docs.sun.com. The larger issue of providing SGML/nroff manpage source is being investigated by those in the documentation group. As with all Solaris projects, the manpages will be put back to the manpage consolidation while the code will be putback to ON. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] inode numbers on ZFS
ZFS inode numbers are 64 bits. The current implemenation restricts this to a 48-bit usable range, but this is not an architectural restriction. Future enhancements plan to extend this to the full 64 bits. 32-bit apps that attempt to stat() a file whose inode number is greater than 32 bits will return EOVERFLOW. 64-bit apps and largefile aware apps will have no problems. The ZFS object allocation scheme always tries to allocate the lowest object number first, so you will never have files with greater than 32-bit inode numbers until you have 2^32 files on the system[1]. There is little expectation that anyone will be able to fill a ZFS filesystem, ever[2]. There is reasonable expectation, however, that in the next 10-20 years we will pass the 64-bit limit for some use cases. Hope that helps. - Eric [1] The actual algorithm allows for some fuzz factor, so this could theoretically occur at 75% of 2^32 files. [2] For a complete discussion of these limits, see Jeff's blog: http://blogs.sun.com/roller/page/bonwick?entry=128_bit_storage_are_you -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] inode numbers on ZFS
On Wed, Oct 12, 2005 at 10:34:49AM -0700, Alan Coopersmith wrote: So does this mean 32-bit apps that didn't need to be largefile aware in the past because they only touched small files now need to become largefile aware to avoid problems with ZFS if they call stat()?(Granted, they've already had problems with stat() with out-of-range dates from NFS servers and other places, but those aren't as common as ZFS will be.) Yes, unfortunately this is the case. But it will only affect filesystems with more than 3 billion files on them. There's not much that can be done about this - if you want to have more than 2^32 files, you need more than 32 bits to uniquely identify them. The lightweight ZFS filesystem model will also reduce this effect, since administrators will be encouraged to have many filesystems (i.e. one per user) instead of a single mammoth filesystem (all of /export/home). - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] inode numbers on ZFS
Yes, there are multi-petabyte systems out there. Though you may disagree, I personally don't think its unreasonable to expect such filesystems to pass the 16 exabyte range within the next 20 years. Neither did the ZFS designers, hence the 128-bit capability. Note that we are talking about filesystems, not individual disks. ZFS filesystems can span any number of disks, just as you could achieve by layering on top of a volume manager or through a distributed filesystem. Besides just being flat out larger, the growth rate of filesystem size not directly proportional to the growth rate of disks. - Eric On Wed, Oct 12, 2005 at 07:50:49PM +0200, Joerg Schilling wrote: Eric Schrock [EMAIL PROTECTED] wrote: There is little expectation that anyone will be able to fill a ZFS filesystem, ever[2]. There is reasonable expectation, however, that in the next 10-20 years we will pass the 64-bit limit for some use cases. Do you believe that there currently already systems with 2000 TB? During the past 17 years, the capacity of a single 3.5 disk did increase by a factor of 2000 (a factor of 1.57 per year). In 20 years, the capacity of a single disk will increase by a factor of ~ 8000. J?rg -- EMail:[EMAIL PROTECTED] (home) J?rg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] inode numbers on ZFS
On Wed, Oct 12, 2005 at 09:28:52PM +0100, Peter Tribble wrote: How far has this been tested? I know I tested it, just to see how well it worked, about 6 months ago. On a fairly small machine, 10,000 filesystems was starting to get interesting. I just wonder, seeing as we would need about 40,000 filesystems under this model. If I remember correctly, most of your problems were relating to performance under these situations (lots of filesystems). Much work has gone into improving performance; I don't know for a fact if we've tried the 40,000 filesystem model. Right now the priority is getting ZFS out the door, and our performance efforts are focused around getting individual filesystems to perform well. I can say for a fact that there is a lot of low hanging fruit in the administration tools to make various operations (listing, deletion, etc) go faster. It's just not something we've been able to focus our efforts on. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Re: Sparc ? x86 Comparison
On Tue, Oct 11, 2005 at 02:14:16PM -0700, S Destika wrote: Every statement of mine claiming Linux is faster than Solaris was backed with specifics (Faster at creating processes, threads, etc. for e.g.) and numbers - Solaris bug database, SPEC benchmarks proving Linux SMP scalability is not as bad as what people claimed without numbers. Anything without proof, numbers and specifics is FUD. You know now who was FUDing. Ok, enough of this. Looks like all that's going to stop this flamewar is to say L1nux is teh suck3r Solaris rulez. Again, what exactly is the response you're hoping for? Multiple people on multiple occasions have acknowledged that Linux is faster than Solaris on some benchmarks. It seems to me like all you want to do is rehash the same points over and over ad infinitum and counter any disagreement as vehemently as possible. If you want to help Solaris performance, you should do one of the following: 1. Work with the performance group (via perf-discuss) to make sure that the benchmarks you think are important are being run internally to identify regressions. 2. File a bug with a specific, repeatable benchmark with clear results comparing Solaris to insert OS here. 3. Take an existing Solaris performance bug and root cause the underlying performance problem, adding the necessary data to the bug report. 4. Take an existing Solaris performance bug, create a fix, and ask someone to sponsor (via request-sponsor) your change. AFAICT you have done none of the above, so I'm not sure what you hope to accomplish via this thread. If you don't want to help Solaris performance, why bring it up on osol-discuss in the first place? - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Fwd: Re: [osol-discuss] Unionfs for Zones
On Sat, Sep 10, 2005 at 10:34:29AM -0700, Octave Orgeron wrote: Does the snapshot take a full copy of the filesystem or does it only copy the delta changes? If it's just regular snapshot, it does not meet the features a union fs can provide. I've only used ZFS in a Solaris 10 course, but it was a year old version:( So I'm not too familiar with what has happened over the past year in development. ZFS is a copy on write filesystem (similar to WAFL), so a snapshot is an instantaneous operation that initially consumes zero additional space. As the active data diverges from the snapshot, it will gradually take up more space, proportional to the amount of delta between them. In addition, ZFS supports the notion of a clone, which is a writable filesystem whose initial contents are that of a snapshot. Like snapshots, a clone initially takes up no extra space, but will consume more over time as the data diverges. We are actively thinking about how these technologies can be used with Zones and Live Upgrade (among other cases) to enable rapid deployment and upgrade. The idea of creating a template zone on a ZFS filesystem and then being able to instantaneously clone a new zone into existance is certainly appealing. But we're currently focused on ZFS integration; this is clearly a phase two item. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Unionfs for Zones
On Mon, Sep 12, 2005 at 07:03:16AM -0700, Octave Orgeron wrote: But now that I know ZFS will have space-efficient r/w clones, I may be able to defend the castle as it were;) I know this must be a question you get a lot.. but here it is.. Is there a way to test out a pre-release version of ZFS? I realize we'll have to sign NDA's and what not, but it's definitely something I'd be interested in. Octave - We're currently in the end game for ZFS development - pushing full speed towards integration (I won't make claims about an exact time frame). We considered a more accessible beta program (as well as opensolaris.org hosting), but it was not an efficient use of team resources at this point in time, and would likely delay the eventual integration into Nevada. We promise we're doing everything possible to get ZFS putback ASAP. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Bug fix process overly burdonsome ?
Steven - Thanks for the input - it's certainly valuable to understand external perception around what we're doing. Some specific responses are below. On Mon, Aug 29, 2005 at 10:17:47PM -0400, Steven Destika wrote: I am not sure if I can advise nor do I have a concrete plan but all I can sayis that you guys need to penetrate more into the community - via conferences,online tutorials, driver writing fest - ideas are not scarce. Over the last several years, we've sent Solaris engineers to several of the major conferences, including USENIX, LISA, and OSCON. Within the last year we've expanded this presence (including LinuxWorld and FISL), and we're looking to expand even further. See: http://www.opensolaris.org/jive/thread.jspa?threadID=1805tstart=15 Part of this expansion is to not have just Sun employed engineers, but also external members of the community present (for example, Ben was at the Sun booth at LinuxWorld). Are there particular conferences that you think we're missing? If so, you should add to that thread. On top of that, there are user groups popping up all over the place: http://www.opensolaris.org/os/community/os_user_groups/ The idea of online tutorials or classes is being worked on as well: http://www.opensolaris.org/jive/thread.jspa?threadID=1749tstart=45 A collection of HOWTOs has also been fronted by the community (can't find the jive reference). The driver writing fest is an interesting idea. I think the first step would be to create a driver community (which I believe has been proposed before - not sure where it stands). We need more detailsin the blogs - not just dtrace scripts - how about Solaris scheduler function, howabout DTrace implementation details etc.? No offense, but did you read the opening day blogs? If not, check out Bryan's earlier response. Just a quick search for DTrace implementation details: http://blogs.sun.com/roller/page/bmc?entry=dtrace_safety http://blogs.sun.com/roller/page/bmc?entry=solaris_10_revealed http://blogs.sun.com/roller/page/ahl?entry=dtrace_user_land1 http://blogs.sun.com/roller/page/ahl?entry=pid_provider_exposed http://blogs.sun.com/roller/page/ahl?entry=dtrace_is_open http://blogs.sun.com/roller/page/mws?entry=dtrace_inlines_translators_and_file Plus, if you're interested in a certain area, it would be entirely reasonable to post a message to opensolaris-code requesting someone to do a blog entry covering a particular subsystem. Or come to IRC and harass any of the engineers who hang out there for more info. There's tons of code in OpenSolaris and we don't always know what people are interested in. There is very less known about Solariskernel code by even lesser number of people which needs to be fixed - I am not saying it is an overnight job - but none the less there has to be significant effort around developer evangelism and spreading of the technical knowledge. Key is to enable mere mortals to contribute good quality code. We're all here. We answer questions on the OpenSolaris forums, comp.unix.solaris, Yahoo! groups, IRC, and direct email. We're blogging, we're going to conferences, we're holding user groups. We're continually forming communities and collecting information. What more should we be doing? What makes other open source projects more appealing? Since you asked - Right now to me, the perception is that there is less technical and more insert that damn BUR??... word here talk. Well, opensolaris-discuss is just that: a discussion. If you want a more technical details, you should look on opensolaris-bugs, -code, -rfe, or one of the many communities. Not to mention one of alternative outlets described above. Of course several have denied that and at the same time assured that we will get there soon - so I have, for now granted folks the benefit of insufficient time if you will.. And I would like to apologize if I did hurt anybody's feelings - I know you guys are hard at workand I have seen some true zeal here to make OpenSolaris a success. I am sure things will besorted out soon and hacking OpenSolaris will be both easy and fun. I guess Mike's point (and mine) is that we seem to be doing all the things you suggest. We are trying really hard to create a successful community, but we can't improve our approach unless we know what we're doing wrong. Besides do it faster and do it more (both of which are limited by resources) are there any specific things we aren't currently working on that would improve the experience? - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] No kernel source updates?
On Wed, Aug 24, 2005 at 10:30:01PM +0200, Felix Schulte wrote: On 8/24/05, Patrick Mauritz [EMAIL PROTECTED] wrote: On Wed, 2005-08-24 at 22:14, Felix Schulte wrote: any comments? see http://www.openbios.org/~oxygene/opensolaris.txt.bz2 Is there no Bonsai/CVSblame for the source tree at opensolaris.org? for what changed in the various source drops (06-12, 07-01, 07-20, 08-18) These are code drops but contain zero content information *why* things were changed (3rd claim from IRC: Sun provides no changelog and per-issue source diff, making the project useless for non-sun contributors). Both of these issues (revision history and putback logs) are being worked on. There is tons of work still left to do, but I'd hardly say this makes the project useless for non-sun contributors. We've already had several external folks successfully contribute code to the OpenSolaris source. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why is Solaris x86 limited to 21 CPUs?
On Wed, Aug 24, 2005 at 10:47:31PM +0200, Felix Schulte wrote: Why is Solaris x86 limited to 21 CPUs (http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/sys/machparam.h#51)? Is there simply no hardware with more than 20 CPUs or are there other limits in the kernel which cause this limitation (SPARC uses 64+576)? This is largely historical. There is a bug: 5081104 NCPU has been outgrown on x86 I'm not sure if there is a good reason (besides lack of resources/priority) why it hasn't been increased yet. Incidentally, these questions are better asked on 'opensolaris-code' (or opensolaris-bugs). - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Sun-FireTM-V240 uses NCPU=554 CPUs for its kernel, others 558
On Wed, Aug 24, 2005 at 10:51:25PM +0200, Felix Schulte wrote: Bug or feature? Sun-FireTM-V240 uses NCPU=554 CPUs for its kernel, others 558 (http://cvs.opensolaris.org/source/search?q=DNCPUdefs=refs=path=hist=) You'll notice that the line is commented out in the Makefile: #MACHINE_DEFS += -DNCPU=554 So it has no effect (and rightly so). This has been there since the initial putback, so it looks like the project team borrowed the Makefiles from Serengeti/Starcat and never really removed it. So yes, this is a bug in the sense that the Makefile is unclean, but it's not a functional problem. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] bite-size bugs
On Wed, Jun 29, 2005 at 08:48:16PM +0200, Jasse Jansson wrote: And how will the community test those fixes in a proper way? Are the special test tools needed (yeah, I know they exist) or will 'continuous use' count as testing? Well, I'm not on the 'test list', maybe I should subscribe to that one too. The testing will be based on the scope and content of the bug. For a simple fix to a utility, it may be sufficient to simply roll your own handmade regression tests. For more complicated changes, such as those to libraries, kernel, or system interfaces, your sponsor will help you get the testing resources that you need. For the near future, this will likely involve you providing BFU archives and having your sponsor submit them to various test runs. If you're interested in how we plan to make testing more accesible, or have suggestions about what needs to be done, you should definitely subscribe to the test discussion list. - Eric -- Eric Schrock, Solaris Kernel Development. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
