trees have some organization problems. Personally I prefer
BSD one and more dislike Linux one. IMHO this is matter of taste.
By the way is this your first feeling or you have some experience with
BSD hacking? (e.q. try to start programming using other language or
other environment, the first feeling
On Wed, Mar 30, 2005, David Leimbach wrote:
Yes, procfs rules!
Procfs is from linux?
I thought it was from Plan 9... along with rfork :).
Nope. It was first implemented by Sun's Roger Faulkner in SVR4,
well before Linux or Plan 9 existed. Actually, someone wrote a
prototype for Unix
On Thu, Mar 31, 2005 at 07:20:13AM -0500, David Schultz wrote:
On Wed, Mar 30, 2005, David Leimbach wrote:
Yes, procfs rules!
Procfs is from linux?
I thought it was from Plan 9... along with rfork :).
Nope. It was first implemented by Sun's Roger Faulkner in SVR4,
well before
On Thu, Mar 31, 2005, Christoph Hellwig wrote:
On Thu, Mar 31, 2005 at 07:20:13AM -0500, David Schultz wrote:
On Wed, Mar 30, 2005, David Leimbach wrote:
Yes, procfs rules!
Procfs is from linux?
I thought it was from Plan 9... along with rfork :).
Nope. It was first
On Thu, Mar 31, 2005 at 08:16:42AM -0500, David Schultz wrote:
procfs comes from v8 (research) unix, a direct predecessor of Plan 9,
way before SVR4.
That's the prototype I was talking about, but I believe it was not
an official part of version 8 (to the extent that anything was).
It
i cann't reply to all of ur comments
but , that is what makes u break off , as DragonFly split of u
u took my opinion as an attack,
u just wanna flaming,
u also got off topic CVS and SVN,
my words were really facts Mr Scott , Linux layout is better than
FreeBSD layout , FreeBSD performance it
Le Mercredi 30 mars 2005 à 09:30 -0800, mohamed aslan a écrit :
i cann't reply to all of ur comments
but , that is what makes u break off , as DragonFly split of u
u took my opinion as an attack,
u just wanna flaming,
*shrug*
u also got off topic CVS and SVN,
That's a
the organization of FreeBSD's sources?
Ok, have fun :).
u took my opinion as an attack,
u just wanna flaming,
u also got off topic CVS and SVN,
You have to keep in mind that what you intended may not come through with
the way your email reads. Popping into a forum and saying this sucks is a
sure
On Wed, 2005-Mar-30 09:30:47 -0800, mohamed aslan wrote:
u took my opinion as an attack,
Your phrasing was provocative (though at least you agree that it's
just your opinion - elsewhere, you continue to claim that your
opinions are facts).
u just wanna flaming,
Given your statements, I was
mohamed aslan wrote:
guys this is not a flame war
but the linux way in arranging the source file is really better than
freebsd way, it's a fact.
Nope. It's real difficult to organize the files worse than in Linux.
FreeBSD is actually real good. Way better than UnixWare, and
of course
Yes, procfs rules!
Procfs is from linux?
I thought it was from Plan 9... along with rfork :).
-SB
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL
On Tue, 2005-Mar-29 10:50:32 +0300, Giorgos Keramidas wrote:
A file may be repo-copied to a new location, then removed from the HEAD
branch in the old location and deleted from the rest of the branches in
the new location. This way the history will be there, in both places
but the file will only
The biggest problem is keeping history here. Doing something like that
with CVS is a major PITA. We didn't have any old release, so moving
the repository files didn't create a problem. That's impossible in
FreeBSD land :)
wasnt here some discussion about moving FreeBSD to subversion (as some
are just more familiar to Linux kernel.
I am not a kernel hacker, like you and many people here. But I usually
read source codes, FreeBSD and also NetBSD and Linux, specially the
areas where I am a particular curious. FreeBSD code organization is
close to BSD's roots (you can get those Walnut
From: mohamed aslan [EMAIL PROTECTED]
Subject: Re: organization
Date: Tue, 29 Mar 2005 07:41:25 -0800
guys this is not a flame war
but the linux way in arranging the source file is really better than
freebsd way, it's a fact.
however it's easy to rearrange it in 1 min as someone said before
mohamed aslan wrote:
guys this is not a flame war
but the linux way in arranging the source file is really better than
freebsd way, it's a fact.
however it's easy to rearrange it in 1 min as someone said before.
but i mean this step should be done from the core team.
for example all fs has to go
Warner Losh wrote:
From: mohamed aslan [EMAIL PROTECTED]
Subject: Re: organization
Date: Tue, 29 Mar 2005 07:41:25 -0800
guys this is not a flame war
but the linux way in arranging the source file is really better than
freebsd way, it's a fact.
however it's easy to rearrange it in 1 min
Iasen Kostov wrote:
Warner Losh wrote:
From: mohamed aslan [EMAIL PROTECTED]
Subject: Re: organization
Date: Tue, 29 Mar 2005 07:41:25 -0800
guys this is not a flame war
but the linux way in arranging the source file is really better than
freebsd way, it's a fact.
however it's easy to rearrange
On Tue, Mar 29, 2005, Warner Losh wrote:
From: mohamed aslan [EMAIL PROTECTED]
Subject: Re: organization
Date: Tue, 29 Mar 2005 07:41:25 -0800
guys this is not a flame war
but the linux way in arranging the source file is really better than
freebsd way, it's a fact.
however it's easy
At 7:41 AM -0800 3/29/05, mohamed aslan wrote:
guys this is not a flame war
but the linux way in arranging the source file is really better
than freebsd way, it's a fact.
however it's easy to rearrange it in 1 min as someone said before.
but i mean this step should be done from the core team.
for
In message: [EMAIL PROTECTED]
David Schultz [EMAIL PROTECTED] writes:
: On Tue, Mar 29, 2005, Warner Losh wrote:
: From: mohamed aslan [EMAIL PROTECTED]
: Subject: Re: organization
: Date: Tue, 29 Mar 2005 07:41:25 -0800
:
: guys this is not a flame war
: but the linux way
[EMAIL PROTECTED] wrote:
And the worts of all is that You are both right to some extent. The
new developers want the source tree arranged in the way mohamed says it
should be. Not some device drivers live in pci/ other in dev/ and things
like that. And on the other hand experienced
In message: [EMAIL PROTECTED]
Divacky Roman [EMAIL PROTECTED] writes:
: The biggest problem is keeping history here. Doing something like that
: with CVS is a major PITA. We didn't have any old release, so moving
: the repository files didn't create a problem. That's impossible in
:
On Tue, Mar 29, 2005, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
David Schultz [EMAIL PROTECTED] writes:
: On Tue, Mar 29, 2005, Warner Losh wrote:
: From: mohamed aslan [EMAIL PROTECTED]
: Subject: Re: organization
: Date: Tue, 29 Mar 2005 07:41:25 -0800
On Tue, Mar 29, 2005 at 05:05:38PM +0200, Divacky Roman wrote:
wasnt here some discussion about moving FreeBSD to subversion (as some other
projects did - samba, mono etc.)? and subversion solves this...
Yes, a few people have looked at it from time to time (raises hand as
one of the guilty
[EMAIL PROTECTED] wrote:
You've proven my point exactly: Some folks want to see i386 moved to
arch/i386, others think it is stupid to do that. Discussion isn't
possible here, so nothing will happen since there's no compelling
reason to do anything, just a weak argument about how things
mohamed aslan wrote this message on Tue, Mar 29, 2005 at 07:41 -0800:
Also, learn not to top post... it looses context...
guys this is not a flame war
but the linux way in arranging the source file is really better than
freebsd way, it's a fact.
well, as I stated in a previous email, if you
]
: Subject: Re: organization
: Date: Tue, 29 Mar 2005 07:41:25 -0800
:
: guys this is not a flame war
: but the linux way in arranging the source file is really
better than : freebsd way, it's a fact.
: however it's easy to rearrange it in 1 min as someone said
before
If memory serves me right, Craig Boston wrote:
On Tue, Mar 29, 2005 at 05:05:38PM +0200, Divacky Roman wrote:
wasnt here some discussion about moving FreeBSD to subversion (as some other
projects did - samba, mono etc.)? and subversion solves this...
Yes, a few people have looked at it
On Tue, Mar 29, 2005 at 11:22:19AM -0600, Craig Boston wrote:
The last I heard, subversion did not scale well to the massive amount of
files that are in the FreeBSD repository. IIRC it's been a while since
this was tested, so it may or may not be true anymore. SVK may
partially address this
On Tue, Mar 29, 2005 at 01:25:19PM -0800, Bruce A. Mah wrote:
Well, someone's part-way there with a Subversion mirror of src/. From
http://www.freebsd.org/support.html:
A public Subversion mirror of the FreeBSD src/ CVS repository is
provided at svn://svn.clkao.org/freebsd/.
Ah, yes, I do
On Tue, Mar 29, 2005 at 11:34:11PM +0200, Joerg Sonnenberger wrote:
That's not true. There are two major problems with subversion, compared
to CVS:
- the size of the working copy is doubled (because of the local cache)
- annotation is linear in the number of revisions (of a file?)
Not trying
If memory serves me right, Craig Boston wrote:
On Tue, Mar 29, 2005 at 01:25:19PM -0800, Bruce A. Mah wrote:
This of course doesn't include ports/ or doc/, so it doesn't really
answer the scalability question.
Most of what I ran into was just in src/. I hesitate to say anything
since
At the risk of going further and further off-topic from
freebsd-hackers...
On Tue, Mar 29, 2005 at 02:29:13PM -0800, Bruce A. Mah wrote:
Sounds like a bad situation there. On our server we use svn+ssh, except
for a few Windows clients that use https. (BTW our server is running
4-STABLE and
hi guys
it's my first post here, BTW i was a linux hacker and linux kernel
mailing list member for 3 years.
and i've a comment here , i think the freebsd kernel source files
aren't well organized as linux ones.
___
freebsd-hackers@freebsd.org mailing
mohamed aslan wrote this message on Mon, Mar 28, 2005 at 10:01 -0800:
it's my first post here, BTW i was a linux hacker and linux kernel
mailing list member for 3 years.
and i've a comment here , i think the freebsd kernel source files
aren't well organized as linux ones.
If you are going
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 28 Mar 2005, mohamed aslan wrote:
hi guys
it's my first post here, BTW i was a Linux hacker and Linux kernel
mailing list member for 3 years.
and I've a comment here , i think the freebsd kernel source files
aren't well organized as Linux ones.
On Mon, Mar 28, 2005 at 01:42:16PM -0500, c0ldbyte wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 28 Mar 2005, mohamed aslan wrote:
hi guys
it's my first post here, BTW i was a Linux hacker and Linux kernel
mailing list member for 3 years.
and I've a comment here , i
mohamed aslan wrote:
hi guys
it's my first post here, BTW i was a linux hacker and linux kernel
mailing list member for 3 years.
and i've a comment here , i think the freebsd kernel source files
aren't well organized as linux ones.
You are in some ways correct..
Unfortunatly, as our project
c0ldbyte wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 28 Mar 2005, mohamed aslan wrote:
hi guys
it's my first post here, BTW i was a Linux hacker and Linux kernel
mailing list member for 3 years.
and I've a comment here , i think the freebsd kernel source files
aren't well
it out.
Fully seconded. Even though it clearly wasn't a brilliant idea to
criticize FreeBSD source code organization without giving a single
reason or example, Mohamed clearly didn't deserve to be flamed like
this. A bit more diplomacy wouldn't hurt here...
Now responding to Mohamed, I'm really
On Mon, Mar 28, 2005 at 11:05:30AM -0800, Julian Elischer wrote:
As things have changed, some of the original layout decisions have
become rather
outdated. For a slightly better example, check out the layout of the
DragonflyBSD kernel
sources. Matt took the oportunity to re-arange the
Maybe you are just more familiar to Linux kernel.
I am not a kernel hacker, like you and many people here. But I usually
read source codes, FreeBSD and also NetBSD and Linux, specially the
areas where I am a particular curious. FreeBSD code organization is
close to BSD's roots (you can get
sources a tangled mess.
This sort of whining isn't productive. Why don't you think they are
organized? Because the organization is different than Linux? Or some
other reason?
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org
The user mohamed aslan wrote this strange object...:
hi guys
it's my first post here, BTW i was a linux hacker and linux kernel
mailing list member for 3 years.
and i've a comment here , i think the freebsd kernel source files
aren't well organized as linux ones.
On Mon, 28 Mar 2005 23:49:25 +0200 (CEST), Webmaster Shizukana.net
[EMAIL PROTECTED] wrote:
The user mohamed aslan wrote this strange object...:
hi guys
it's my first post here, BTW i was a linux hacker and linux kernel
mailing list member for 3 years.
and i've a comment here , i think
The user David Leimbach
On Mon, 28 Mar 2005 23:49:25 +0200 (CEST), Webmaster Shizukana.net
[EMAIL PROTECTED] wrote:
The user mohamed aslan wrote this strange object...:
hi guys
it's my first post here, BTW i was a linux hacker and linux kernel
mailing list member for 3 years.
and
mohamed aslan wrote:
hi guys
it's my first post here, BTW i was a linux hacker and linux kernel
mailing list member for 3 years.
and i've a comment here , i think the freebsd kernel source files
aren't well organized as linux ones.
I left a job last year where I developed linux kernel code
On 2005-03-28 21:17, Joerg Sonnenberger [EMAIL PROTECTED] wrote:
On Mon, Mar 28, 2005 at 11:05:30AM -0800, Julian Elischer wrote:
As things have changed, some of the original layout decisions have
become rather outdated. For a slightly better example, check out the
layout of the DragonflyBSD
DFly has incorporated a new organizational structure for gcc3 and
binutils214 that FreeBSD might want to take a look at.
Basically it works like this:
* The vendor code in /usr/src/contrib is named after the major version
release, so e.g. we have /usr/src/contrib/gcc-3.3
Hi Bruce,
A few thoughts on your API:
1) Rather than naming the struct's as l1, l2 etc, it may be more
orthogonal to use an array of cache entries like so
struct entry { ... } entries[MAX_ENTRIES]; where MAX_ENTRIES would be say,
8.
2) We could pass information back about whether the
Bruce M Simpson wrote this message on Mon, Oct 13, 2003 at 20:32 +0100:
i386 pc98 amd64
---
Action: Add code to identcpu.c to fill out hw_cacheinfo.
Cache discovery: Extended CPUID.
Static tables if 486-class machine. No cache on 386.
TLB discovery: Extended CPUID.
Static
On Sun, Oct 12, 2003 at 08:57:52PM +0100, Bruce M Simpson wrote:
[ Andrew: Perhaps you can shed some light on how the necessary information
can be gathered on Alpha? My search was incomplete and I could not find
a reliable source for DEC's development manuals. ]
L1 cache information is in the CPU
Peter Jeremy wrote:
On Sun, Oct 12, 2003 at 08:57:52PM +0100, Bruce M Simpson wrote:
[ Andrew: Perhaps you can shed some light on how the necessary information
can be gathered on Alpha? My search was incomplete and I could not find
a reliable source for DEC's development manuals. ]
L1 cache
All,
Here are detailed design documents for determining cache and TLB
geometry across our currently supported processor architectures,
with recommendations outlined for implementation.
What I haven't addressed yet is how indirect consumers of the API might
use it, e.g. mutex consumers vs. UMA,
Hi,
ISTR that AMD 486 had different cache arrangements from Intel. Just threw
one out - I'll see if I can find another around here.
--
Bob Bishop +44 (0)118 977 4017
[EMAIL PROTECTED] fax +44 (0)118 989 4254
___
[EMAIL
All,
I came up with the attached text file today to summarize some of my
findings, after looking at various open source trees to see how they
handle run-time cache geometry detection.
Many will find it ironic that i386 is the easiest platform to deal with.
[ Andrew: Perhaps you can shed some
On Sat, Oct 11, 2003 at 01:58:27PM +1000, Peter Jeremy wrote:
If you do this, it may make sense to use the same names as MacOSX.
What if your hardware has different linesizes for different caches?
I noticed whilst peering in Apple Developer Notes that G5 has 128 byte
cache line size, and
On Sat, Oct 11, 2003 at 09:27:11AM +0100, Bruce M Simpson wrote:
OS X definitions considered too PowerPC centric. I think the best way
to handle all cases is thus:-
- Support 3 levels of cache.
Out of interest, do any systems other than the big-iron Alpha's use L3
cache? A quick look at the
On Sat, Oct 11, 2003 at 08:12:31PM +1000, Peter Jeremy wrote:
Out of interest, do any systems other than the big-iron Alpha's use L3
cache? A quick look at the code suggests that only L2 is coloured.
L3 cache is present on many MIPS and Pentium Xeon systems, as well as
PowerPC G4.
Do any
Hi -hackers,
I'm looking for ways that a userland program can determine the CPU
features available on an SMP machine -- processor model, stepping
numbers, supported features, cache organization etc.
For example, on some x86 processors the CPUID instruction could be
used to determine some
On Fri, 10 Oct 2003, Joseph Koshy wrote:
Hi -hackers,
I'm looking for ways that a userland program can determine the CPU
features available on an SMP machine -- processor model, stepping
numbers, supported features, cache organization etc.
For example, on some x86 processors the CPUID
On Fri, Oct 10, 2003 at 03:36:40AM -0700, Joseph Koshy wrote:
I'm looking for ways that a userland program can determine the CPU
features available on an SMP machine -- processor model, stepping
numbers, supported features, cache organization etc.
What Silby said and have a look
, cache organization etc.
What Silby said and have a look at the sysutils/x86info port.
Hey, cool, I'd never heard about this.
Just tried this, and got some wierdness. Can I ask about it here,
or do I poke at the port maintainer?
I've been thinking we should definitely make the cache
Bruce M Simpson writes:
I've been thinking we should definitely make the cache organization
info available via sysctl. I am thinking we should do this to make
the UMA_ALIGN_CACHE definition mean something...
If you do this, it may make sense to use the same names as MacOSX.
Eg:
g51
On Fri, Oct 10, 2003 at 03:09:47PM -0400, Andrew Gallatin wrote:
Bruce M Simpson writes:
I've been thinking we should definitely make the cache organization
info available via sysctl. I am thinking we should do this to make
the UMA_ALIGN_CACHE definition mean something...
If you do
On Fri, Oct 10, 2003 at 03:09:47PM -0400, Andrew Gallatin wrote:
Bruce M Simpson writes:
I've been thinking we should definitely make the cache organization
info available via sysctl. I am thinking we should do this to make
the UMA_ALIGN_CACHE definition mean something...
If you do
Hi,
My doubt is whether freebsd uses the normal mbuf clusters in case of large amount
of data (like jumbogram in ipv6 or the maximum ipv4 datagram size of 65536 bytes)?
My understanding is that for such a large amount of data, clusters which can hold
only 2048 byes are not economical.
Hi,
My doubt is how data will be organized in buffers in case we want to transmit large
amount of data.
My doubt is regarding the organization of mbufs in case we want to transmit the
maximum ip datagram size.
In the normal case data is stored in clusters for data size greater than
On Tue, May 15, 2001 at 08:15:56AM -0400, [EMAIL PROTECTED] wrote:
My doubt is whether freebsd uses the normal mbuf clusters in case
of large amount of data (like jumbogram in ipv6 or the maximum ipv4
datagram size of 65536 bytes)?
FreeBSD provides two standard types of storage (mbufs and
70 matches
Mail list logo
