Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
/usr/src/... Why when Linus says not to?
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
GenKreton
l33t
l33t


Joined: 20 Sep 2003
Posts: 828
Location: Cambridge, MA

PostPosted: Sat Jul 17, 2004 11:35 pm    Post subject: /usr/src/... Why when Linus says not to? Reply with quote

Why does gentoo use /usr/src/ when in Linus and those kernel guys say not to?
And why do they say not to?

Just curious to as why a whole distribution (that I love and use solely mind you) ignores the kernel guys.


Last edited by GenKreton on Sun Jul 18, 2004 3:41 pm; edited 1 time in total
Back to top
View user's profile Send private message
Voltago
Advocate
Advocate


Joined: 02 Sep 2003
Posts: 2584
Location: userland

PostPosted: Sat Jul 17, 2004 11:37 pm    Post subject: Reply with quote

Where does Mr Torvalds want us to put the kernel sources instead?
Back to top
View user's profile Send private message
pkdawson
Retired Dev
Retired Dev


Joined: 16 Jul 2004
Posts: 146
Location: Long Island or Buffalo, NY

PostPosted: Sat Jul 17, 2004 11:41 pm    Post subject: Reply with quote

I think he means this:
http://www.linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html

He says not to compile the kernel as root, which seems a bit overly paranoid to me. It's a little hard to understand exactly what he means, but I think he just doesn't want people symlinking /usr/src/linux to the real linux sources directory. I don't see why that's a problem, though.

BTW, I've never seen a single distro that doesn't use /usr/src. Care to point one out?
Back to top
View user's profile Send private message
robmoss
Retired Dev
Retired Dev


Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford

PostPosted: Sat Jul 17, 2004 11:45 pm    Post subject: Reply with quote

No, Linus does not say to avoid putting kernel sources in /usr/src/linux. What Linus says is to avoid symlinking the kernel headers from /usr/src/linux. The kernel headers live in /usr/include/linux. There are also kernel headers in /usr/src/linux/include/linux. What Linus does not want people to do is the following:

Code:
cd /usr/include
ln -s linux ../src/include/linux
ln -s asm ../src/include/asm


It's perfectly alright to have the kernel sources in /usr/src/linux, as long as you don't have those two symlinks up there. It's nicer if you can have the relevant kernel sources in /usr/src/linux as well, but this doesn't sit well with a distribution that has installable modules - which is every distribution there is. That old post from Linus where he mentions that his /usr/src/linux still contains the 2.2.13 headers isn't relevant as of 2.5.70, I don't think.
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts
Back to top
View user's profile Send private message
robmoss
Retired Dev
Retired Dev


Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford

PostPosted: Sat Jul 17, 2004 11:49 pm    Post subject: Reply with quote

Just a follow-up to that - pkdawson - Gentoo and LFS, and indeed a couple of others, have a way out with regards that post from Linus, because we are what he refers to as "the people who actually make library releases and compile their own glibc".
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts
Back to top
View user's profile Send private message
GenKreton
l33t
l33t


Joined: 20 Sep 2003
Posts: 828
Location: Cambridge, MA

PostPosted: Sun Jul 18, 2004 12:04 am    Post subject: Reply with quote

Alright I think I understand better now.

Its comments like:
"people still remember that the linux sources should go into "/usr/src/linux", even though that hasn't been true in a loong time."

That make the whole thing confusing to someone not so well veresed on the subject.
Back to top
View user's profile Send private message
robmoss
Retired Dev
Retired Dev


Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford

PostPosted: Sun Jul 18, 2004 12:12 am    Post subject: Reply with quote

Yes, it is confusing, but to even understand a sentence of a Linus post you have to understand a hell of a lot :P What he means there is that the kernel sources should not always go into /usr/src/linux - only when there's a good reason for them to do so. The /usr/src/linux symlink doesn't actually contain the linux kernel sources on Gentoo, they live (fx) in /usr/src/linux-2.6.7-gentoo-r11. /usr/src/linux is used with, for example, module building. Personally, I believe that the /usr/src/linux situation on Gentoo is still broken, and an eclass for modules should be created that does the following:

1. Remove the /usr/src/linux symlink, if it exists, which it should not.
2. Create a symlink in /usr/src called linux to linux-$(uname -r).
3. Build the kernel module.
4. Remove the /usr/src/linux symlink.
5. Install the module in /lib/modules/$(uname-r)/.

IMHO that would be far preferable, and would make sure that users checked to see that they were actually compiling the right kernel when they compile it.
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts
Back to top
View user's profile Send private message
GenKreton
l33t
l33t


Joined: 20 Sep 2003
Posts: 828
Location: Cambridge, MA

PostPosted: Sun Jul 18, 2004 12:18 am    Post subject: Reply with quote

So you are against linking /usr/src/linux to the kernel you are using (ie: /usr/src/linux-2.6.foo)?

The guide (at least when I first started using gentoo near 2 years ago) suggested to do this. If its not necessary then i will get rid of it on my systems.
Back to top
View user's profile Send private message
robmoss
Retired Dev
Retired Dev


Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford

PostPosted: Sun Jul 18, 2004 12:29 am    Post subject: Reply with quote

It's necessary on Gentoo, but I'm against it. I don't believe it should be necessary. That's why I want to create an eclass: all ebuilds that require that symlink should make it themselves, or be fixed so they don't need it (which should I think be possible in all cases).
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9236
Location: beyond the rim

PostPosted: Sun Jul 18, 2004 1:10 am    Post subject: Reply with quote

robmoss2k wrote:
1. Remove the /usr/src/linux symlink, if it exists, which it should not.
2. Create a symlink in /usr/src called linux to linux-$(uname -r).
3. Build the kernel module.
4. Remove the /usr/src/linux symlink.
5. Install the module in /lib/modules/$(uname-r)/.

Definitely no, that way you could only build modules for the kernel you're currently running, not for a kernel you're going to use after the next reboot.
Back to top
View user's profile Send private message
robmoss
Retired Dev
Retired Dev


Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford

PostPosted: Sun Jul 18, 2004 5:18 am    Post subject: Reply with quote

Genone wrote:
Definitely no, that way you could only build modules for the kernel you're currently running, not for a kernel you're going to use after the next reboot.


Thinking about it, shouldn't we really be building a module for all available kernel source tree sets? You don't need to list /usr/src for this - just look in /var/db/pkg/sys-kernel (and obviously ignore the headers). It always annoys me that I have to fiddle with that symlink just to make sure all the kernels I use get a module. :?
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts
Back to top
View user's profile Send private message
hadfield
Retired Dev
Retired Dev


Joined: 18 Mar 2003
Posts: 308
Location: Vancouver, BC, Canada

PostPosted: Sun Jul 18, 2004 5:36 am    Post subject: Reply with quote

robmoss2k wrote:
Thinking about it, shouldn't we really be building a module for all available kernel source tree sets?


The only problem I can see with that is that you might want to use, say nvidia v5536 with kernel X, but nvidia v4496 with kernel Y. Perhaps because there's an incompatibility with v5536 and kernel Y.

Might be nice if there was a USE flag or something that would allow you to enable/disable this feature though. Not too sure if there would be much demand though, I think most people only run one kernel at a time.
Back to top
View user's profile Send private message
GenKreton
l33t
l33t


Joined: 20 Sep 2003
Posts: 828
Location: Cambridge, MA

PostPosted: Sun Jul 18, 2004 12:37 pm    Post subject: Reply with quote

hadfield wrote:
robmoss2k wrote:
Thinking about it, shouldn't we really be building a module for all available kernel source tree sets?


The only problem I can see with that is that you might want to use, say nvidia v5536 with kernel X, but nvidia v4496 with kernel Y. Perhaps because there's an incompatibility with v5536 and kernel Y.

Might be nice if there was a USE flag or something that would allow you to enable/disable this feature though. Not too sure if there would be much demand though, I think most people only run one kernel at a time.


On all my machines save my server I have at least 2 kernels I try to keep current. I have my heavily patched dev kernels and my more stable and known to be working 2.6.* kernel. This is even more key once 2.7 is getting ready.

I doubt I am alone in doing that.
Back to top
View user's profile Send private message
pkdawson
Retired Dev
Retired Dev


Joined: 16 Jul 2004
Posts: 146
Location: Long Island or Buffalo, NY

PostPosted: Sun Jul 18, 2004 3:35 pm    Post subject: Reply with quote

GenKreton wrote:
On all my machines save my server I have at least 2 kernels I try to keep current. I have my heavily patched dev kernels and my more stable and known to be working 2.6.* kernel. This is even more key once 2.7 is getting ready.

I doubt I am alone in doing that.


And I routinely use a slightly different kernel when I'm using VMware, and I don't want my nvidia or sound modules compiled for it. So that's two different versions of 2.6.7 that I have.
There's also the fact that development-sources is usually on the latest release candidate, which I don't like to use. 2.6.8-rc1, for example, messes up the compilation of Apache Ant (dev-java/ant).
So I really wouldn't trust portage to know about all your kernels.
Back to top
View user's profile Send private message
myuser
Apprentice
Apprentice


Joined: 31 Jan 2004
Posts: 218

PostPosted: Sun Jul 18, 2004 8:11 pm    Post subject: Reply with quote

Hold on, I think Linus means this:

whichever kernel was used to compile glibc should be the one sym linked to by /usr/src/linux.

If you build a new kernel do not do it in /usr/src/ instead the files should be in some other directory.

Compile the kernel as a user non root, and the install the kernel as root.

The whole thrust of his remarks center around which kernel compiled glibc, and that is the kernel that should be symlinked by /usr/src/linux

Now, if the above is true, then Gentoo should not be installing in /usr/src/ but perhaps some other directory. Upon a new glibc being compiled the files should be moved to /usr/src (or perhaps not) and /usr/src/linux should be symlinked to the new kernel that was used when compiling glibc.

Alternatively every time you install a new kernel you should recompile glibc.

I am interested in knowing more about this, as people's responses above actually are directly contradicted in the text in the reply to Mr. Ulrich Drepper, so who is right?

Now there is the idea of the modules having to match the kernel, but is this true?? should they really be matching the kernel that compiled glibc??

You might not see too many errors because you update often (glibc) or the chance for an error is quite slim, or because this is a few years old it has been changed or mutally resoved in some fashion.

Thinking about this a little more, if you are continuosly hacking the c lib glibc, then the situation of sym linking /usr/src/linux to your current kernel makes sense as glibc will be varying all the time, which explains the comment

"""It's a symlink for historical reasons, none of them very good any more (and haven't been for a long time), and it's a disaster unless you want to be a C library developer. Which not very many people want to be.
"""

hmm, so if the installation instructions for the kernel have been written by a glibc dev, or derived from one, then it would appear it is the wrong one for the majority of people.


Last edited by myuser on Sun Jul 18, 2004 8:22 pm; edited 1 time in total
Back to top
View user's profile Send private message
robmoss
Retired Dev
Retired Dev


Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford

PostPosted: Sun Jul 18, 2004 8:20 pm    Post subject: Reply with quote

myuser - no, Linus does not mean that. The headers that glibc were compiled against should live in /usr/include/linux and /usr/include/asm. These are the only headers that should be used by any compile that doesn't create a kernel module. See the bit where he refers to "people who compile their own glibc"? That's us. So we're allowed to put the kernel sources in /usr/src/linux, and particularly so if we make sure that no compiles make use of them except for the building of modules.

The "whole thrust of his remarks" in fact refer to actually putting the sources in /usr/src/linux (which is wrong) rather than symlinking /usr/src/linux to the location of the sources. Further to that, and more importantly, having made that symlink, symlinking /usr/include/linux and /usr/include/asm to /usr/src/linux/include/linux and /usr/src/linux/include/asm, which is really, really wrong.

In short, don't unduly worry yourself. This has been gone through a thousand times before by people far more knowledgable about the kernel and its headers than you, I or anyone else who posts on these forums. Trust me, there's nothing particularly wrong with the current setup. Don't worry about it!
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts
Back to top
View user's profile Send private message
myuser
Apprentice
Apprentice


Joined: 31 Jan 2004
Posts: 218

PostPosted: Sun Jul 18, 2004 8:32 pm    Post subject: Reply with quote

I am not so sure, whilst I haven't had any problems I imagine that is because the interfaces don't vary much.

I don't compile my glibc everytime I install a new kernel, and I suspect you don't, glibc is compiled once with the first kernel unless you explicitly update glibc, and this is true of all distros. Just because you compile your kernel, so what someone has to do it.

But I would be interested to see you explain concisely what this means:

"""
But then you link that program (with the new "struct X") to the binary library object archives that were compiled with the old header files, that use the old "struct old_X" (which used to be X), and that use the old system call entry-points that have the compatibility stuff to take "struct old_X".


Boom! Do you see the disconnect?
"""

So struct X varies:

eg.

glibc:
struct X {
int y;
};

new kernel expects:
struct X {
int y;
int z;
};

doesn't find z and bombs. ( because glibc is out of date with your kernel, but the checks by the kernel code are not valid as you have updated the /usr/src/linux sym link).

I think we are being protected because glibc does not vary much. Which is scant protection for sods law.


>>> The "whole thrust of his remarks" in fact refer to actually putting the sources in /usr/src/linux (which is wrong) rather than symlinking /usr/src/linux to the location of the sources

I don't think so this is what Linus said.


""" Linus writes:
NOT do so in /usr/src. Leave whatever kernel (probably only the header files) that the distribution came with there, but don't touch it.
compile the kernel in their own home directory, as their very own selves. No need to be root to compile the kernel. You need to be root to install the kernel, but that's different.
"""

When reading the text:

> : is remarks from anyone else.

and Linus refers to himself as he, because one of the respondents did (and he probably saw it as being rude but in a funny way :)) I don't know if this casts more light on the subject.

It goes:

Pine.LNX.4.02.10007270811460.32194-101000@prins.externet.hu, Boszormenyi Zoltan <zboszor@externet.hu> wrote:

Linus

Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard

Linus


>>>So we're allowed to put the kernel sources in /usr/src/linux, and particularly so if we make sure that no compiles make use of them except for the building of modules

The one you compile glibc with but, in the word of Linus:

"""No. He really meant that you should not use the kernel headers: You should use the headers that glibc came with. It is probably a Red Hat bug that those headers were a symbolic link.
"""


Last edited by myuser on Sun Jul 18, 2004 8:47 pm; edited 2 times in total
Back to top
View user's profile Send private message
spb
Retired Dev
Retired Dev


Joined: 02 Jan 2004
Posts: 2135
Location: Cambridge, UK

PostPosted: Sun Jul 18, 2004 8:40 pm    Post subject: Reply with quote

That problem occurs if you compile a userspace program against kernel headers with a different ABI to those used to compile glibc (for example, or any other library that uses kernel interfaces). Now, since we use seperate headers in /usr/include, we can change the contents of /usr/src/linux however often we like, since nothing in userspace is compiled against it. Kernel modules, however, have to be compiled against the right kernel version, so we need the current sources in a consistent location.

The main reason for not changing /usr/src/linux stems from the times when userspace programs were built against headers in /usr/src/linux, and so you needed to keep a consistent set of headers there. Since we don't build anything against that source, we can change it at will.

In summary: times have changed. We don't build stuff against /usr/src/linux any more, so the need to keep it constant has pretty much disappeared.
Back to top
View user's profile Send private message
myuser
Apprentice
Apprentice


Joined: 31 Jan 2004
Posts: 218

PostPosted: Sun Jul 18, 2004 8:46 pm    Post subject: Reply with quote

Ok, well he does not make reference to any old programs.

"""
Think about it a bit.. Imagine that the kernel introduces a new "struct X", and maintains binary backwards compatibility by having an old system call in the old place that gets passed a pointer to "struct old_X". It's all compatible, because binaries compiled for the old kernel will still continue to run ? they'll use the same old interfaces they are still used to, and they obviously do not know about the new ones.

Now, if you start mixing a new kernel header file with an old binary "glibc", you get into trouble. The new kernel header file will use the new "struct X", because it will assume that anybody compiling against it is after the new-and-improved interfaces that the new kernel provides.
"""

he refers explicitly to kernel header files, now time could have moved on, and in some other way this problem is handled, but he is not refering to other programs, he refers to the kernel.

When make modules_install is called there is no problem where the linux source is, it is for nvidia and other third party modules. for those there should be an ability to point it at the correct source, which probably should not /usr/src/linux for the resons stated above, unless something has changed which enables the kernel to detect if glibc supports the features the kernel thinks glibc has.


Last edited by myuser on Sun Jul 18, 2004 8:58 pm; edited 1 time in total
Back to top
View user's profile Send private message
spb
Retired Dev
Retired Dev


Joined: 02 Jan 2004
Posts: 2135
Location: Cambridge, UK

PostPosted: Sun Jul 18, 2004 8:55 pm    Post subject: Reply with quote

He's talking there about kernel headers, and the problems that happen when a userspace application and library are compiled against incompatible versions. As long as all of the userspace is compiled against compatible headers, you're fine, because the kernel contains special code to work with applications that were compiled with old headers.

At the time he wrote that, the standard way of handling kernel headers was either (1) compile against the headers in /usr/src/linux/include/linux, or (slightly more recently) (2) compile against /usr/include/linux, which was a symlink to /usr/src/linux/include/linux. So either way, userspace programs were built against the headers in /usr/src/linux, which was why you didn't want to change them very often.

Now, in our case, we have a seperate package for kernel headers, and they're installed directly in /usr/include/linux. They're completely unrelated to whatever is in /usr/src, and they're specially sanitised for compiling userspace programs, so minor revisions aren't going to break things that way. When there's a major change in kernel headers (eg 2.4 => 2.6), we recompile glibc.

So, we don't need to worry about breakage caused by switching kernels in /usr/src/linux, because the headers used to build userspace programs are completely seperate, and watched closely to make sure that upgrades don't cause that sort of breakage.
Back to top
View user's profile Send private message
myuser
Apprentice
Apprentice


Joined: 31 Jan 2004
Posts: 218

PostPosted: Sun Jul 18, 2004 9:00 pm    Post subject: Reply with quote

>>> When there's a major change in kernel headers (eg 2.4 => 2.6), we recompile glibc

Is this forced by portage (because I have a sneaking suspicion mine wasn't unless it just happened quickly in the background)?
Back to top
View user's profile Send private message
robmoss
Retired Dev
Retired Dev


Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford

PostPosted: Sun Jul 18, 2004 9:02 pm    Post subject: Reply with quote

Urgh. Look. That post is really old. Look at the date it was posted. Some of it is irrelevant (as I said earlier, as of the 2.5.70 kernel). Some of it was irrelevant before that. The kernel you are using when you compile glibc DOES NOT MATTER. That's why we can symlink /usr/src/linux to the current kernel sources. We couldn't do that before glibc-2 though. We now have glibc-2.3.x, so we can. You do NOT have to recompile glibc every time you upgrade your kernel. In fact, you don't ever have to recompile glibc unless you break the kernel headers' backward compatibility with an upgrade - which in theory should NEVER happen, although it did at 2.5.70, which is why this is a problem.

That stuff you wanted explaining concisely - I'll do it as concisely as I can. glibc should keep the header files it was compiled with in /usr/include/linux and /usr/include/asm. If new headers are installed, glibc should be recompiled. The running kernel must be at least as new as the kernel headers. The location of the kernel sources for the currently running kernel does not matter so long as they don't end up in /usr/include/linux and /usr/include/asm. That's all it means. The /usr/src/linux symlink has NOTHING AT ALL TO DO WITH THIS!!! Unless, of course, you symlink /usr/include/linux to /usr/src/linux/include/linux and symlink /usr/include/asm to /usr/src/linux/include/asm - which we don't.
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts
Back to top
View user's profile Send private message
robmoss
Retired Dev
Retired Dev


Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford

PostPosted: Sun Jul 18, 2004 9:04 pm    Post subject: Reply with quote

myuser wrote:
>>> When there's a major change in kernel headers (eg 2.4 => 2.6), we recompile glibc

Is this forced by portage (because I have a sneaking suspicion mine wasn't unless it just happened quickly in the background)?


No, but it should be. It's a well-known open bug, and currently you just get a warning at the end of the linux-headers, or linux26-headers, merge. But nobody has implemented that sort of dependency yet, so we can't fix it.
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts
Back to top
View user's profile Send private message
myuser
Apprentice
Apprentice


Joined: 31 Jan 2004
Posts: 218

PostPosted: Sun Jul 18, 2004 9:27 pm    Post subject: Reply with quote

The post was quite old, and I also thought the issue might have been resolved, so I thought I would wander through the kernel README: ( in /usr/src/linux-2.6.7.gentoo-r8 )

""""
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:

gzip -cd linux-2.6.XX.tar.gz | tar xvf -

Replace "XX" with the version number of the latest kernel.

Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
""""

So, time has moved on, but this message has not changed.

The NOT is capatalized for effect, so there must be some reason for it still.

The only problem I see with shifting the sources is that the install guide would have to recognise someone updating a kernel and installing the first one, and when compiling the 3rd party modules they should be linked to some other location apart from /usr/src/linux (unless that does happen to be your only kernel). So, it is a couple of tweaks.

Oh, and if glibc is recompiled then /usr/src/linux should point to the kernel that compiled it.

Actually that is the switch, so I suppose all kernels should go to another location, then sym link /usr/src/linux when glibc gets compiled. They could stay in /usr/src but I suppose that is causing widespread confusion, as virtually all the install guides say to do what the README says to NOT! do very explicitly.


Last edited by myuser on Sun Jul 18, 2004 9:40 pm; edited 1 time in total
Back to top
View user's profile Send private message
robmoss
Retired Dev
Retired Dev


Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford

PostPosted: Sun Jul 18, 2004 9:36 pm    Post subject: Reply with quote

myuser wrote:
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.


Like I said, this isn't a problem, as we don't use them as headers. IT DOES NOT MATTER! :?
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum